When NOT to use /clr
I notice the new 2005 compiler happily compiles my native projects, even ones that contain inline asm and variable param functions. It just warns me about the native code generated. The managed c++ compiler in 2003 could not handle this. So, why would I ever want to not compile with the /clr option?
I have found in the past that a mixed code application can spend 50-90% CPU time in mscorwks.dll even without a single managed class, just by adding or taking #pragma unmanaged/manged in some files. I am obviously trying to avoid this problem.
If you target a pure native app and not use a single .net framework class... then that's the time to remove the /clr switch...
If you try to make a .net app w/o using any native class then switch to /clr
ure...
AFAIK, VS 2003 has a problem with mixed (manage/native) code... but i think this has been minimized(if possible eleminated) in C++/CLI...
cheers,
Paul June A. Domag
If you ever want to put any .NET into you native app, flip the switch and test it first. In my experience, it can make some applications crawl and even become unstable. These were MFC projects.