Question

I’m considering porting an application C / C + + in C + + / CLI.

Mainly I would like to exploit the potential of reflection, XML serialization and in general all the features in. NET framework offered by Microsoft (maybe even in mono).

The project in question does not use the STL heavily, and application objects are mostly allocated statically. A lot of code is written in C, another was implemented in C + +.

The problem is that the code is very, very, very “long”: this is a problem for the time required for the conversion of the existing code so that it runs properly.

I tried to create a C + + project compiled with flag in / clr, was not so bad after all. you can keep your existing code C + +, but in the meantime use the classes “managed”, is even able to access “managed” objects from C + + class methods.

The flaws that I found very few, but make me puzzled about this “migration” …

To take advantage of the data serialization using reflection, all my data structures should be managed. An unmanaged class can not declare fields as defined by a type of managed class. To resolve this problem if a class is converted so that it is managed by the garbage collector, every class that declares a member of that type to be managed as well.

What difficulties may be encountered during the introduction of managed classes?

Well, I’m thinking about:

• String management (I hate to call AllocaHGlobal to convert System.String to char* each time I need it (for example, as function parameter)
• Array management (conversion of classical arrays to cli::array)
• (already mentioned) mixing managed and unmanaged classes
• exception handling
• crash (core) dump creation how is affected
• …any other that I haven’t thought yet…

Answer 1

Unmanaged classes can have managed members. The trick is to use the gcroot template. Look here

http://weblogs.asp.net/kennykerr/archive/2005/07/12/Mixing-Native-and-Managed-Types-in-C_2B002B00_.aspx

to learn more about it.

EDIT: as a response to some of your other questions: when you have a working C++ code base which is so big that you have to expect change requests from production while in parallel you are working on the C++/CLI port, IMHO the best approach is to avoid having two copies of the same code base. Instead, try to make the same code compilable both with C++ and C++/CLI, using #ifdef‘s, macros, generators etc. I know that’s possible since this is exact what we did some time ago when porting a program of ~120.000 lines of code.

For string conversion, we were using this code:

typedef System::String^ SysString;

inline SysString Std2Sys(const std::string &s)
{
    return gcnew System::String(s.c_str());
}

inline std::string Sys2Std(SysString ss) {
    using namespace System::Runtime::InteropServices;
    const char* chars = 
      (const char*)(Marshal::StringToHGlobalAnsi(ss)).ToPointer();
    std::string s = chars;
    Marshal::FreeHGlobal(System::IntPtr((void*)chars));
    return s;
}

(performance was never an issue with that in our case, might be different in yours, but don’t try to optimize anything if there is not any need to).