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

  • Thread starter Thread starter Hendrik Schober
  • Start date Start date
H

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
 
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?
Click to expand...

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?
Click to expand...

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.
 
SvenC said:
Hi,


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

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
Click to expand...

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

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
 
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?
Click to expand...

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?
Click to expand...

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
 
David Lowndes said:
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#.
Click to expand...

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.
Click to expand...

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
Click to expand...

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
 
Ah, the old GC problem: It helps you deal with memory,
and isn't really helpful when dealing with all the
other resources.
Click to expand...

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

Dave
 
David Lowndes said:
That's it. It all sounds great until you use it in anger and come
across the shortcomings :(
Click to expand...

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
Click to expand...

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
 
Back
Top