C++/CLI: evolving C++ within the .NET platform

ABSTRACT

C++ is 20 years old in 2005 as a supported language. It has proved enormously successful - it drives the major operating systems of our computers, it supports cutting-edge military radar, operation software for space missions, much of the computer animation in film, the telephone switches, and so on. It represents a marriage of the low-level C language with higher-level abstractions such as Object-Oriented and Generic programming. Its object model is optimized for minimal space and time overhead. It permits the programmer to suppress any and each high-level abstraction facility in order to squeeze maximum performance. The canonical extreme C++ program is the offset and indirect access of data through a type-less pointer into raw memory.The Common Language Infrastructure (CLI) represents a radical departure from the C/C++ Object Model. It provides a software abstraction layer between the executing program and the underlying operating system. And within this software layer, much of the logistics of loading and executing a program has been shifted, and this is why the CLI program environment is often referred to as a managed environment. Garbage collection is part of this multi-tiers software architecture, so that it is a facility offered to all languages. Security and verifiability of the executing program are high priorities. A Common Intermediate Language (CIL) provides a shared repository of all languages; this is augmented with a standardized metadata description, both of which are managed by the CLI runtime. In addition, the CLI provides a Common Type System (CTS) to which all CLI languages must support. This type system is not compatible with the C++ Object Model.This provides a number of interesting problems. (a) There are we believe hundreds of millions of lines of C++ code running under Windows that we would like to see moved to run under the CLI. How do you do that without requiring people to rewrite the existing code. That is a poor return on inventory, if you will. So, we need a language that is both compatible with C++ and yet fully supports the CLI. We don't have a choice in terms of our user base. We have to somehow bridge the two worlds. (b) How do you integrate two type systems and two object models that are fundamentally incompatible into a language that is both familiar and yet clearly separates the two models? What sort of language design principles make sense?Finally, how can we understand this work? Have we made C++ a better language by extending it to work with the CLI? Why is this movement so controversial - Gosling, for example, the creator of Java, has claimed that our work is a colossal blunder by Microsoft. That's a pretty serious charge. We didn't think that was what we were doing. I have found it easiest to understand what was necessary for positioning C++ within the CLI runtime environment by viewing it in a Darwinian context in which languages compete for finite resources - program budgets and the hearts and minds of the programmer community.