 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / August 2007C++, C, C#, .NET, and an API
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  SignatureSpamTrap@gmx.de 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 [quoted text clipped - 7 lines] > 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. -- SvenC > Hi, > [quoted text clipped - 11 lines] > > 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? > > Are there any pitfalls we need to look out for? (Like, > > if you do it this way, it could be used from MC++, but [quoted text clipped - 3 lines] > 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 SignatureSpamTrap@gmx.de 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? 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#. >> 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? 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 > > 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#. Thanks for the confirmation (and the hint regarding C#). > > > Biggest pitfall might be object lifetime issues when it comes to your > > > wrapped objects and the garbage collector. [quoted text clipped - 5 lines] > 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 SignatureSpamTrap@gmx.de 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. That's it. It all sounds great until you use it in anger and come across the shortcomings :( Dave > > 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 :( 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 SignatureSpamTrap@gmx.de 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
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.