Cook Computing

Far from correcting any assertions

May 3, 2002 Written by Charles Cook

Far from correcting any assertions I've made here about Managed C++, I'd like to restate two points.

  1. The sample program listed in an earlier posting , when compiled with the /clr option, is a managed program. The result of the compilation is an assembly containing metadata and IL. This is managed code (Challa and Laksberg discuss this in Chapter 2 of Essential Guide to Managed Extensions for C++). Note that I am not saying that the program uses managed types. The program illustrates my point that Managed C++ - when using unmanaged types - can lead to code which contains the bugs that are found in tradititional C and C++ programs, even when writing completely new managed code. When defining a type, the default behaviour is that the type is unmanaged which makes errors even more likely.
  2. My other point was that I fail to see what advantages Managed C++ brings you over C# if you are not doing any interop with legacy code and intend to use only managed types. I can only see disadvantages. Various people have commented on the power of Managed C++ but I have yet to see anyone list the reasons why it is more powerful than C# in a purely managed context. I may be wrong, but if so it is because I am overlooking one or more features of Managed C++, not because the facts I have presented so far are incorrect.

In writing about this my main concern has been to find out why Managed C++ is thought to be more powerful than C# in a purely managed application. If anyone can point out which compelling features of Managed C++ I'm overlooking, please let me know. I'm open to persuasion but until then I'm definitely in the C# camp.