Slashdot Mirror
Microsoft's C++/CLI Spec Has an Identity Crisis
Andy Updegrove writes "Microsoft's submission of its XML Reference Schema to Ecma has gotten lots of attention in recent months, because Microsoft offered it to Ecma to try to neutralize Massachusetts' adoption of the OpenDocument Format (ODF) standard. But last week it's earlier submission of C++/CLI to Ecma was in the limelight when the U.K. representatives to ISO cried foul over (of all things) its name, which they said was confusingly, and inappropriately, similar to C++. Some think that there may be more afoot, including the potential for Microsoft to add proprietary extensions after ISO finally adopts the new standard under a different name. Either way, the C++/CLI experience represents an interesting dry run for what to expect as Microsoft pushes the XML Reference Schema throught the same process."
C++/CLI seems to be a (standardized) proprietary extension to the C++ language that allows it to interface well with the rest of the .Net architecture. It's not a huge departure from the core language by any means, at least not enough of one to require a complete name change.
Compilers have no sense of humour. If a language is not ISO C++, it is not C++ and should not have C++ as part of the name. I'm dating myself, but I've worked with "FORTRAN" compilers that didn't support FORTRAN 77 (which was the standard at the time) and to all intents and purposes they were not FORTRAN compilers--they were "some proprietary FORTRAN-like-language compilers" and completely useless if you wanted to compile many perfectly ordinary FORTRAN programmes.
The issue here is that the use of the C++ name is a big marketing issue. But to apply the C++ name in any variant to a language that is not C++ is fundamentally misleading and dishonest. This is because humans are lazy and stupid, and tend to drop the modifier and think of "C++/CLI" as simple "C++"--the article points out that MS documentation has many examples of code samples labelled "C++" with no "CLI" modifier that are not, in fact, C++. They are C++/CLI.
And as I said, compilers have no sense of humour--they don't care that "C++/CLI" is "almost" C++. They see non-standard syntax and barf. So it is very important for those of us who want our code to compile and who want to be able to communicate with others to keep the name "C++" as pure as possible. This isn't being uptight--it is a purely pragmatic concern about keeping marketing droids as far from technology as possible so that software professionals can communicate with each other as clearly and unambigously as possible given the limitations we all have as human beings.
Blasphemy is a human right. Blasphemophobia kills.
But the problem is that MS has taken to calling it.. C++. We already have a C++. If you look at MSDN they have C++.Net code all over the place, but they never call it that. They always call it C++. They make a C++.Net complier, but they just call it C++. From what I've read, they seem to be almost purposely trying to confuse the difference between C++ and C++.Net.
The worry seems to be that if this standard is ratified, MS will continue this practice. One can argue they have done this in the past, trying to confuse J++ and Java (J++ being their "version" of Java). While this all does seem a bit nit-picky, I think it is important.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
(And some opinions too; I'll leave you to work out which are facts and which are opinions.)
It's the UK's panel that has submitted this paper to ISO; the UK panel is part of BSI, the British Standards Institute, one of the NB's (National Bodies) making up ISO.
The biggest problem is that ISO should not publish two standards which are for such different languages with such similar names, and encourage the confusion. Standards are there to reduce confusion, not to contribute to it.
And make no mistake, C++/CLI is a huge departure from the core language. It introduces a whole new type of pointer, it adds generics to C++ templates, it abandons const-correctness for core using "ref" classes, it has yet another string type (this time somewhat integrated into the language rather than being a pure library entity), it adds mandatory garbage collection (C++ has always permitted, but not required, GC, though with some caveats) in a way not consistent with previous work with GC in C++, and there's more I'm sure.
It's also a concern that C++ may wish to expand into areas overlapping with those that are covered by Microsoft's language "C++/CLI", and may not wish to do so in the same way as C++/CLI, which is mostly just one of a pile of vendor-specific extensions to C++.
ISO is about standardizing existing practice. Some of the biggest problems with existing C++ and C standards has been when they got too inventive, and accepted into the standards things that were implemented in few (or no) compilers. So far as I know, there's still only one compiler that supports C++/CLI (though I've a feeling one other company is working on one).
Microsoft and the ISO C++ groups have been getting along a lot better in the last few years; Microsoft returned to attending committee meetings, and hired some great people, both names that get publicity and some that don't. However, Microsoft is still a large company with a monopoly in certain areas, and some history of anticompetitive practices, and it seems sensible for us to tread carefully.
As a matter of Stroustrup has commented. In a nutshell, he says that Microsoft is revising their documentation to minimize confusion.
Stroustrup's comment. Apparently Microsoft is revising their documentation to clear up the confusion.
You're comparing apples to oranges.
Stroustrup didn't go around "casually" referring to C++ as C using a multi-million-dollar PR machine. On the contrary, he has written extensively about the relationship between C++ and C as the newer language has evolved, and has always been clear about the significance of having similar syntaxes and where the differences start.
Microsoft, on the other hand, frequently do refer to C++/CLI simply as C++. They even have a column on their MSDN web site called Pure C++; would you like to guess whether the C++ in question is the ISO standard variety or the C++/CLI one? That one's a real shame, and I'd have expected better from a distinguished C++ expert like Stan Lippman.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
C++/CLI or C++/.NET is essentially: C++.
This is false. To you all the nice people who have thoughtfully replied to my comment with pedantic outrage, let me remind you what hummassa (157160) has pointed out in a mysteriously low-moderated response:
C++/CLI will not compile the STL.
This has been my own experience with C++/CLI, and one of the primary reasons for my being so hard-assed about the name. This is not a minor deviation from the standard. It is a radical deficiency. The STL is a core piece of any C++ programmer's toolkit, and any compiler in 2006 that will not compile it is not a C++ compiler, and should never be refered to as C++, and should not have a name that could possibly be confused with C++.
This is like having a FORTRAN compiler that can't handle LAPACK. If I created something called FORTRAN/CLI that couldn't compile LAPACK people would rightly yell at me. MS deserves to be smacked on the nose with a rolled up newspaper for doing the equivalent to C++.
Blasphemy is a human right. Blasphemophobia kills.