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++ Continues Linux's Invasion
651 (DCLI)
C++ Command Line Interface
The name, as submitted, is a sufficient train-wreck that people savvy enough to know a compile shan't confuse it with something they want. Possibly it will appeal to the PHB audience.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
..as Microsoft pushes the XML Reference Schema throught the same process.
thought + through = throught != a well perused article summary.
This doesn't seem to be anything more than someone who's got his panties in a bunch about Microsoft and is creaming between his thighs about the chance to stick it to the Man.
.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.
.Net, etc) and on the other hand you've got a group who is relatively unwilling to give Microsoft the time of day.
C++/CLI seems to be a (standardized) proprietary extension to the C++ language that allows it to interface well with the rest of the
On the one hand, you've got Microsoft who is willing to label various related products under one brand (Windows,
I'm not saying that ISO's wrong, but they could certainly stand to pull that rod out of their collective asses.
No kidding. ".net++" would be kind of sane.
I actually think that's a pretty good analogy
Dammit!
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.
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.
The same argument could have been advanced against the name C++ itself: "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." Along these lines, I don't see anything wrong with something like "C++ Extensions for CLI" so long as the name makes it clear that it's an extension to C++98 and/or C++0x.
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.
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
.NET technologies, then C++/CLI is perfect. Any C++ coder worth anything will know that the term "C++" by itself does not fully describe a C++ project's language.
What a load of crap.
C++ was well established on all major platform long before ISO standardized it. I know I've written my share of #ifdef/#define's to make code more portable between IRIX and othe *nix variants in my 15 plus years of C++ coding.
If you want to write a (mostly)cross-platform C++ program then use ISO C++. But if you want to reuse your C++ code and integrate it with newer
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.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
So I guess there weren't any C++ compilers between 1997 when the language was standardised and some time around 2001 when the compiler vendors started catching up with the features that had been included in the spec?
Perhaps my copy of Borland C++ 4.5 from ~1994 isn't a C++ compiler at all, because the language hadn't been standardised when it was written?
Here's a clue for you: in the real world, we call a compiler a C++ compiler if it compiles C++ code. It doesn't have to compile *all* C++ code for this to be true, just a useful subset. If it complies with the spec, so much the better. These we'll call ISO C++ compilers if we're in the mood to distinguish between them.
The same happened with C when it was first standardised. The standard described a language substantially different from what older compilers understood and compiled, but those compilers didn't cease being C compilers just because they couldn't compile all the code that the spec said complying compilers had to. They just weren't ANSI C compilers.
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.
The difference between the cases you all made is simple:
0. C++ (at one time, at least) EXTENDS C
1. moc/Qt EXTENDS C++
2. C++Builder "properties" and VCL EXTENDS C++
but
2. C++/CLI LIMITS C++ (no multiple inheritance, no metaprogramming, etc etc) -- more than it extends it (.net class libraries)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
> 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.
It sure as hell isn't fine with me. I use multiple inheritance a lot, and if Microsoft's language doesn't support it, that means I would have to throw away (or at least, radically redesign) most of my existing code in order to use their compiler. The whole point of having a standardized language specification is so that you can migrate existing code without rewriting it. So their new language may be many things, but without multiple inheritance it's not C++.
I don't care if it's 90,000 hectares. That lake was not my doing.
Right, I could use a cross-language interface layer, the same as if I had written the code any other non-compatible language. Which is the point: Without MI, C++/CLI is not C++ in any meaningful sense of the term. It's a separate, similar-but-incompatible language, much like C# or Java.
And gratuitous use of multiple inheritance is bad design, so you might want to think about that. Yes it's a good thing sometimes, but this is VERY RARE - it always increases complexity and can cause problems later, it's just that sometimes the benefits are worth it.
I agree that it's very easy to misuse multiple inheritance and get into trouble, and I have been bitten by that in the past. From those experiences I was able to learn where MI is helpful and where it isn't, and now I use it only when it's appropriate. But really, whether MI is considered "good", "bad", or "ugly" is beside the point -- it's an integral part of C++, and a language that doesn't support it simply can't claim to be "C++ ".
I don't care if it's 90,000 hectares. That lake was not my doing.