A few days ago on news:comp.lang.c++.moderated, "Chris" asked:

  • Here is a paranoid question: Is there a possible future step, where compiling C++ on a Microsoft plaftform becomes impossible _without_ using the CLI binding?

No. Doing that would mean throwing away all the ISO conformance work that Visual C++ just spent nearly the whole last release cycle adding to the product. VC++ is now 98%-ish conformant to C++03 (the 1998 ISO C++ standard + its first technical corrigendum) and VC++ will continue to work on the remaining 2%, plus track the coming C++0x additions as they are created by the ISO and ANSI committees.

Of course, the CLI extensions will be needed where programs specifically take advantage of CLI (i.e., .NET) data types and features, such the types in the .NET Frameworks libraries, and garbage collection and reflection. But programs that don't need those can ignore the extensions and compile just fine to either native binaries or to .NET IL. Note that last bit, because it seems to be not widely known: C++ code can still be compiled to IL and run in the .NET virtual machine (Common Language Runtime, or CLR) without using any extensions; the extensions are needed only for additionally using CLI data types and features like garbage collection.

So there are three major scenarios:

  • Pure native: Compile existing programs to native binaries just like we've all been doing for years. No CLI features, no CLI extensions.
  • Normal C++ programs that happen to be compiled to IL instead of to x86: The code runs on the VM and is JITted and everything, but the program is still using all native data and not using any CLI data types, so no CLI extensions are needed here either.
  • C++ programs that explicitly start using some CLI data types or features: At those points in the code where those data types or features are used, and only at those points, the extensions will apply, and most of the time the only new syntax will be to write gcnew and ^ (instead of new and *).

Unless you're actually authoring your own new CLI types, you're unlikely to directly use much more than gcnew and ^, plus maybe an occasional sprinkling of nullptr or %.