470,815 Members | 1,175 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,815 developers. It's quick & easy.

dotnet or MFC

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.

Apr 19 '06 #1
2 1540
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.

Apr 19 '06 #2
Hi Jeff!
If it were me, I would make an adapter for String^ and std::string and go
with C++/CLI.


A simple and powerful (means that you do not need to take care of
freeing the string explicit) conversion is:
#using <mscorlib.dll>
using namespace System;
#include <tchar.h>
#include <string>

class String2CSTR {
public:
String2CSTR(System::String ^s) throw(...)
:
cp(static_cast<char*>(System::Runtime::InteropServ ices::Marshal::StringToHGlobalAnsi(s).ToPointer()) )

{ }
~String2CSTR() throw()
{

System::Runtime::InteropServices::Marshal::FreeHGl obal(static_cast<System::IntPtr>(cp));

}
operator const char*() const throw()
{
return cp;
}
private:
char* cp;
};

int _tmain()
{
String ^s = "Hallo";
std::string str = String2CSTR(s);
return 0;
}
Greetings
Jochen
Apr 19 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by GChong | last post: by
reply views Thread by Justin Kennedy | last post: by
reply views Thread by Joe Bloggs | last post: by
4 posts views Thread by Peter Hemmingsen | last post: by
4 posts views Thread by Peter Plumber | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.