Share via

Q: Could the CLI binding become required? A: No.

  • Article

A few days ago on ,
"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 % .