Cook Computing

Sam Gentile replies to my

May 1, 2002 Written by Charles Cook

Sam Gentile replies to my previous posting:

Umm, there is nothing managed about this "Managed C++" program and thus you will not get any of the CLR benefits. I think you may be confused about Managed C++ and this is common. As I say in my book, in Chapter 7, compiling with /clr will not make *any* of your data managed. It just changes compilation to emit IL in an assembly. All of the data is *still unmanaged* and coming from the unmanaged heap. That's why you have the problems above. Only the types you specifically mark with __gc or __value will become managed and the problems will go away.

My understanding is that managed code and managed types are orthogonal to each other. Managed code (produced when using the /clr option) consists of IL and metadata - which is what I see when I compile this sample program and look at its assembly using ILDASM, I don't see any native x86 unmanaged code. Managed types are allocated in a garbage collected heap and their deallocation is under the control of the garbage collector. Managed code can use unmanaged types. Hence the gist of my posting that using Managed C++ is likely to result in code which suffers from all the problems of C and C++.

A corollary to this: if you code using Managed C++ with only Managed types, and so produce safer code (but lose much of the power of C++), what advantage does Managed C++ bring you over C#? I can see disadvantages - such as the need for header files in programs with more than one source file and having to use __gc (and being careful never to omit it) - but I can't see any advantages. This is not argument for the sake of argument, I see comments such as this (Stan Lippman on an application strategy for Managed C++ in the foreword to Essential Guide to Managed Extensions for C++):

Writing directly in the .NET environment the same as you do in C# or Visual Basic, but with more access to the underlying .NET architecture.

and wonder what it is I'm missing.