To read all comments associated with this story, please click here.
> It's easier to migrate existing C++ code to C++/CLI
> than it is to migrate it to C#.
I wouldn't be too sure of that. The changes in the destructor and constructor semantics alone would drive any C++ to C++/CLI porter up the wall. This would be especially true if your app uses any MFC or STL. I've done C to C++ porting. From experience, subtle differences (like the implicit typedef definition of structs and the C++ 'bool' type) can be a lot more maddening than blatently different features (classes, templates, etc). With subtle differences, your code still runs but you get the wrong behaviour and it's hard to recognize what's wrong because the old code "makes sense". With blatent differences, the compiler screams at you until you fix the problem.
Given the differences, to me it would make a lot more sense to either wrap your C++ code in a COM object and import that (.NET appears to integrate seemlessly with COM objects) or leave your pure C++ code alone and use .NET's PInvoke to call it from C#.




Member since:
2005-07-06
What's the advantage of using this "thing" instead of C#? Performance?