Pitfalls when converting C++/CLI to C++
I have a library written in C++/CLI and I want to open it up. I want it to be as cross-platform a开发者_运维知识库s possible and be able to write bindings to it for other languages to use (Java, Python, etc, etc). To do this, the library needs to be in plain C++ for maximum flexibility. I figure that the logical structures are already there, I just need to replace the .NET libraries it uses with the standard C++ ones. Is this a misguided notion? What should I watch out for when making this transition?
It might be more trouble than it's worth. Here is what you might come across:
- There is no garbage collection in C++. This is the big one. This may require a significant redesign of your library just to convert. If you are using at least C++ tr1, or the boost library, you can sort of get there by using shared_ptr, but there are important fundamental differences. For example, you must be wary of circular dependencies. Also, they make debugging difficult without specific support for them in the debugger.
- Functions in .Net classes which have no equivalent in C++ stl or the standard library. Probably the biggest hurtle will be any string manipulation code you have written since there are lot of differences there.
- Class libraries/assemblies are not built-in to C++ - every platform has its own method of creating dynamic or shared libraries, and there isn't much support for C++ shared libraries - only C libraries in many cases. Be prepared to make everything a static library.
- You must manage all your resources yourself.
Never done a port of C++/Cli to C++, but this comes to my mind:
- Make sure that you dont have memory leaks. Use smart-pointers instead of gcnew, if possible (if not, make sure your code is exception safe nontheless).
- Make sure your libraries interface only consists of builtin types (builtin does not include types of the STL! however this is not coercively necessary if you go open source)
精彩评论