C++, C, C#, .NET, and an API

[Hendrik Schober]

Hi,

we have a few libraries programmed in C++ which are
accessible through C APIs. (There's a C++ API wrapping
around one of those C APIs, if that helps.) These are
well tested and work for quite a few customers. Now we
start getting requests for a C# API. Being a dedicated
cross-platform shop, we never did any .NET stuff and
have no experience in this. So here's a few questions:

From what I learnt by reading here it seems the easiest
way to expose our stuff to C# would be to wrap those
APIs wuith managed C++. Is that right?
Are there any pitfalls we need to look out for? (Like,
if you do it this way, it could be used from MC++, but
not from C#, so you better do it that way...)
Anything else we need to consider?

TIA,

Schobi

--
(e-mail address removed) is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier

 

[SvenC]

Hi,

we have a few libraries programmed in C++ which are
accessible through C APIs. (There's a C++ API wrapping
around one of those C APIs, if that helps.) These are
well tested and work for quite a few customers. Now we
start getting requests for a C# API. Being a dedicated
cross-platform shop, we never did any .NET stuff and
have no experience in this. So here's a few questions:

From what I learnt by reading here it seems the easiest
way to expose our stuff to C# would be to wrap those
APIs wuith managed C++. Is that right?

Managed C++ is deprecated. With VS2005 you now have C++/CLI.

Are there any pitfalls we need to look out for? (Like,
if you do it this way, it could be used from MC++, but
not from C#, so you better do it that way...)
Anything else we need to consider?

Never did it myself. You might start here:
http://msdn2.microsoft.com/en-us/library/bhc3fa7f(VS.71).aspx

Biggest pitfall might be object lifetime issues when it comes to your
wrapped objects and the garbage collector.

 

[Hendrik Schober]

Hi,


Managed C++ is deprecated. With VS2005 you now have C++/CLI.

Ah, so that's what it's called this year.
Still, if we'd wrap the APIs using this, they'd be
accessible from C#, right?

Never did it myself. You might start here:
http://msdn2.microsoft.com/en-us/library/bhc3fa7f(VS.71).aspx

Ah. Thanks.

Biggest pitfall might be object lifetime issues when it comes to your
wrapped objects and the garbage collector.

Mhmm. Care to elaborate? I thought using .NET is all
about not having to consider object lifetimes? (Since
I haven't programmed in a GC'ed language in >10 years,
this might be a dumb question. Sorry.)

Schobi

--
(e-mail address removed) is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier

 

[David Lowndes]

Ah, so that's what it's called this year.

Still, if we'd wrap the APIs using this, they'd be
accessible from C#, right?

Generally yes. I "design" the interface in C# terms and then implement
it in C++/CLI - so I'm sure it'll be accessible from C#.

Mhmm. Care to elaborate? I thought using .NET is all
about not having to consider object lifetimes?

That's what the early marketing led many to believe (no memory leaks),
but object lifetime for things like file handles, network connections,
etc. are as relevant as they always were.

If you implement them in C++/CLI life is easier though as the
destructor does pretty much what you'd expect . The C#/VB callers
need to make use of the using construct to ensure the object is
disposed in the face of any exceptions.

Dave

 

[Hendrik Schober]

Generally yes. I "design" the interface in C# terms and then implement
it in C++/CLI - so I'm sure it'll be accessible from C#.

Thanks for the confirmation (and the hint regarding C#).

That's what the early marketing led many to believe (no memory leaks),
but object lifetime for things like file handles, network connections,
etc. are as relevant as they always were.

Ah, the old GC problem: It helps you deal with memory,
and isn't really helpful when dealing with all the
other resources.

If you implement them in C++/CLI life is easier though as the
destructor does pretty much what you'd expect . The C#/VB callers
need to make use of the using construct to ensure the object is
disposed in the face of any exceptions.
Thanks!

Dave

Schobi

--
(e-mail address removed) is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier

 

[David Lowndes]

Ah, the old GC problem: It helps you deal with memory,

and isn't really helpful when dealing with all the
other resources.

That's it. It all sounds great until you use it in anger and come
across the shortcomings

Dave

 

[Hendrik Schober]

That's it. It all sounds great until you use it in anger and come
across the shortcomings

I always wondered what's so good about the runtime
environment taking care of cleaning up one of a
potentially infinite set of possible resources.

Dave

Schobi

--
(e-mail address removed) is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier