C++ divided by CLI
Programmers agitated by Microsoft's approach
At the ACCU conference recently, one wag in the audience referred to Microsoft’s C++/CLI as “C++ divided by CLI”, which neatly summed up the prevailing mood. The 10,000 classes in .NET can’t work with ISO C++, and you may ask why anyone in their right mind would try to bring out a platform in this day and age that couldn’t talk directly to C++.
Earlier, a Microsoftie had asked how many were developing for Vista, and the only person who admitted to this worked for Microsoft. Given the audience of pathological early adopters, someone at Redmond should be worrying about this.
Up pops Herb Sutter, architect of C++/CLI and a real programmer. Few other people could get away with calling their blog “guru of the week”, without getting laughed at; and he’s reinforced his credentials with a stint as chair of the ISO C++ committee. This makes him quite happy to take on an audience of knowledgeable sceptics. Apparently, Microsoft seriously considered not having C++ as a first class language, because of the hole it’d dug itself into with its API. Fortunately, Herb & co prevailed against this counsel of despair. Microsoft has always prospered on winning the hearts and minds of developers, and clearly looked over the void here.
What is a Standard?
Everyone accepts that Microsoft doesn’t have to follow any standards process for C++ (they do? – Ed). There is nothing to stop it sticking in whatever bits of C# or VB suit its purpose, or simply not including things it doesn’t like. So Microsoft’s attitude to C++/CLI does look better than Sun’s grip on Java to many people. Almost all C++ vendors have extensions, and this has contributed to the dominance of both C and C++.
But Ecma standardisation is a fast track process in which suppliers/vendors can agree things, and users of the technology just get what they are given, with no input; and where backwards compatibility just may, or may not, happen. As the ECMA website says, “ECMA is driven by industry to meet the needs of industry, generating a healthy competitive landscape based on differentiation of products and services”.
The real stakeholders in a language are, by contrast, mostly not vendors; and they care a lot about compatibility and the openness of a standard. Your code will still need support in 10 years, when the hardware you wrote it on is in an African landfill. This makes proper ISO standardisation a lot more important. Whatever Microsoft’s record in other areas, Visual C++ produces high quality code and conforms very well to the standards, making it one of the good guys. But the move to make C++/CLI an ISO standard worries people because of the confusion it will cause.
Roger Orr’s take is that Microsoft’s join to CLI is actually too good, making people worry about the future of the standard. “Managed Extensions for C++” quickly became known as Managed C++ even in Microsoft documentation, but managed C++ now languishes in obscurity. However, name drift from C++/CLI to plain C++ is a burning political issue in the standards process.
The Lobster Pot
All C++ bindings contain stuff to make using the underlying system easier. Microsoft C/C++ had the infamous
HUGE keywords to cope with Intel’s brain damaged segmented memory architecture. Compilers have flags to alter the way parameters are passed onto the stack; and structures are packed to allow access to the system or library. All of these things can be turned off at one point in the command line, or by
#defines, or at worst simple search and replace.
Thus, you can port VC++ code to (say) Linux relatively easily; provided, of course, that the Win32 specifics are distinct. Largely, C++/CLI is a superset of C++, and Microsoft has made a commitment to track ISO C++ as a subset. However, the option to warn of extension use doesn’t actually work, helping to reinforce the parting of C++ and C++/CLI into different languages.
The design rationale for C++/CLI is here.
What are the differences?
The 24 extra keywords in C++/CLI compare to 63 in C++, so this is a big change, Microsoft has been cunning in putting them either in places where there’s no keyword currently; or in breaking with C++ tradition and using keywords with spaces (which has quite annoyed some); so avoiding future clashes. This discipline has made life hard for the VC++ team, and of course, even harder for its competitors.
C++/CLI introduces yet another flavour of reference, which is quite unlike that already in use, being more like the handle pattern; and amongst its “features” is that comparison of handles isn’t safe. But it’s a massive improvement upon the misleading use of * style pointers in Managed C++. Object references can only point to “whole” objects, which isn’t much of an issue; but it’s rather more fiddly that they can’t live on the C++ dynamic heap. Neither can they be cast and/or copied, making them feel slightly alien to the idiomatic C++ coder.
Microsoft has been a good citizen on its use of
for each; agreeing to use an “ugly syntax” in order to stay out of the way of the ISO people trying to decide on a good syntax. However, it does make assumptions about the names of members of containers, which some people do not like at all. Nevertheless, Herb’s gang should be very proud of the elegant way that garbage collection is handled. They’ve separated resource from memory release, giving in effect a “lazy free”, neatly supporting the Resource Acquisition Is Initialization idiom rather better than Java. There is also a good interaction between generics and templates.
But the differences that seem to have caused more loathing than anything else are having inheritance become public by default in managed classes; and making functions pure virtual by default in interfaces. This means that an interface has a more complex effect than you’d think. The main difference between a POD struct and a class has always been this first step towards encapsulation and this ripples through the structure of your program, altering the meaning and correctness of overloads and pure virtual functions.
Why Does this Matter?
If your life is like so many others, churning out code to work on Microsoft platforms, this doesn’t matter. Because Microsoft eats its own dogfood with VC++, using it to develop its own products, and has real C++ people like Herb, this stuff works well, with VC++ producing excellent code and conforming well to standards. But it can be confusing, as Java-style garbage collection breaks many common C++ idioms for tight resource handling, not just memory. But if your boss gives you a lump of C++/CLI code to port, thinking it’s C++, you and s/he are going to have very different views on how long it will take; not that Microsoft is going to cry too much over this.
Stroustrup’s Name Taken in Vain
Finally, Stroustrup has said that he’s quite happy for there to be a C++/CLI and doesn’t see the Microsoft “bindings” as bad. However, he seems rather less keen on there being another ISO standard beginning with C++, because of the confusion it would cause, and he’d have preferred a library style binding. A UK response to Microsoft wanting C++/CLI as an ISO Standard is here. ®
[Origins of "C++ divided by CLI": Reg Developer author Kevlin Henney has confirmed that he was the particular wag using it this time, and that he's been using it for a couple of years; but he's no longer sure if he actually invented it or whether it simply emerged in a discussion he was involved in - Ed.]