I am not sure about converting between String^ and std::string. I also don't
use the obfuscators so I don't know how well they work. I am assuming they
work fine.
As for your other questions, I can say that it is not a bad thing that
assemblies don't compile to native. However, if this a requirement for you
then you can compile the assemblies to native images after they are
deployed. The utility for that is called ngen.exe (Native Image Generator).
Also, C++/CLI has deterministic destructors now. You can call delete on a
managed object. That will call its destructor and claim your memory
immediately instead of waiting for the garbage collector.
If it were me, I would make an adapter for String^ and std::string and go
with C++/CLI. Yeah, .NET takes up more memory but there are so many benefits
that I don't consider the extra memory an issue. I remember when people
complained about having to ship MFC's DLL because it required so much memory
too.
<du****@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...
Hi,
I'm starting a new project and am still torn deciding whether to go
with MFC or to do it in C++/CLI with dotnet. The app makes extensive
use of C++ native libraries which cannot go managed (closed source) and
will have a whole pile of UI. Dotnet is way easier for UI than MFC but
it doesn't compile to native. How much of a speed hit is dotnet UI and
converting back and forth between String^ and std::string*? Do the MSIL
obfucsators work at all? Dotnet seems to be a huge memory hog as well
and GC is kind of slow to reclaim memory. Also, the VC2005 built-in
leak detector seems to be missing (my test project is mixed managed and
unmanaged).
Thanks.