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.
The prominent C++ expert Herb Sutter is the lead architect of C++/CLI.
He also chair the ISO C++ standards committee.
(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.
C++/CLI is, in fact, a strict superset of C++. Any C++ code that compiles without the /clr flag should compile without any complaints with the /clr flag. Linking, however, is another story. Because the result of a /clr linking is different than a native linking, there is no guarentee that C++ code will link correctly.
.NET brand) IS STILL C++
"Managed C++" or "C++ with Managed Extensions" or "C++/CLI" or "C++.net" or whatever you want to call it (Microsoft has done a very poor naming job with the entire
http://brandonbloom.name
Generally, bash is superior to python in those environments where python is not installed.
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.
For example, Qt introduces signals and slots as an extension, but the same effect can be achieved with libsigc++ or boost::signals, making intelligent use of the template system. Smart pointers and garbage collection have been demonstrated by boost::shared_ptr and so on.
I understand that in the past weaknesses in implementations of C++ made some of these extensions necessary, but now that we have compliant compilers that actually implement almost all of the language standard, there are less and less reasons to create proprietary extensions to it.
This is completely wrong.
.NET byte code and executed in the .NET FrameWork.
.NET System Classes like System.Int32 etc.
.NET) like threading etc. and finalization has to have a counterpart in C++/.NET which is defined in C++/CLI.
.NET mitght look like:
... } // finalizer - called after/during GC ... } // destructor (like in standard C++) ... } // ....
... I could imagine tehy are only generics, but I think they are still templates like in Visual C++).
.NET then only use C++/.NET to port/interface with existing C++ code, otherwise all those subtible changes that are made in C++/.NET versus ordinary C++ (or MS Visual C++) will drive you completely mad!!
C++/CLI might be the name of the standard, what it means is: having a standard that defines how C++ is compiled to
C++/CLI or C++/.NET is essentially: C++. However with added tweakes like finalizers (yepp, thats not a destructor), (optional) garbage collection bublic/private classes liek in C#/Java and a mapping from primitv data types on
Further all primitive datatypes have a determined size, unlikey ISO C++ where still only char <= short <= int <=long is valid which means often that char == 1 byte and the rest is 4 bytes.
Finally a lot of typical C# (or
a typical C++ clas in
public class __gc MYClass {
!MyClass() {
~MyClass() {
MyClass() {
}
HINT: don't write new programms in C++/.NET except you need fancy stuff like templates (but I'm not sure how templates exactly work in C++/.NET
If you need to write new code in
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
> Does c++.net run ansi c++ code? Then its C++
Long answer: NO. C++/CLI does not have multiple inheritance; it does have generics, which are templates without the metaprogramming possibilities -- because it does not have templates. Henceforth, the STL does not work under C++/CLI. Nor does Boost.
It does have annotations on classes and methods, reference/value class dichotomy, garbage collection built-in (as opposed to library-based), finalizers (one strange kind of destructor), its generics have type restrictions (like the new templates planned for C++0x -- of which I'm not a big fan)
It's as different from C++ as is C# or Java, really.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
You're still missing my point. You fundamentally assume that all developers are aware of portability issues, standardisation issues, the technical details of exactly what is and what isn't in ISO C++, the nature of Microsoft's .Net platform and the C++/CLI language, and so on.
Take a look at any C++ newsgroup, preferably one of the unmoderated ones with a lot of newbies asking for help. Observe their level of understanding (or otherwise) of exactly how even standard C++ works. They frequently don't "get" concepts like undefined behaviour, compiler extensions, and standard vs. non-standard libraries. A huge number of the problems posted on such groups come directly from making that sort of mistake; some groups have dozens of examples every week. Some people will even aggressively defend their misconceptions, telling other (correct) posters that they don't know what they're talking about because "it works on my compiler". This has been happening with GCC extensions for years, and it's already happening with Microsoft extensions as well.
So yes, I'm completely convinced that there are huge numbers of new and inexperienced programmers out there who really won't appreciate the significance of tying themselves into Microsoft's platform. Moreover, it is naive to pretend that Microsoft doesn't know this very well. Their whole marketing strategy, which the BSI guys are rightly challenging, seems to be based on creating this ambiguity in people's minds. I've mentioned the "Pure C++" column and random blog post misterminology elsewhere in this thread. There are simpler things too, like highlighting C++/CLI reserved words even when you're editing native C++ code in the IDE, as if they were a part of standard C++, and including C++/CLI and .Net material prominently in help pages even when nothing implying this platform is selected in the filters.
I'm no arbitrary MS-basher -- go ahead and check my previous posts, and you'll find sometimes I support them and others I don't -- but in this case, I think they have a blatant strategy for trying to abuse the system, and it's quite right that those responsible for maintaining that system call them on it. If they had tried this with any well-known language with a major commercial backer, they would have been sued into oblivion by now, probably with a court order not only preventing standardisation under their derivative name but also preventing them from even marketing their own product with it.
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.