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."

Comments

Re:The name _is_ confusing.

[r00t]

No kidding. ".net++" would be kind of sane.

Re:Sounds like a molehill masquerading as a mounta

[radtea]

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.

Plus Plus!

[tepples]

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.

Re:Plus Plus!

[CaymanIslandCarpedie]

I preface this by saying I know I'm being anal (sorry) ;-)

c++/cli is NOT descended from c or c++. Its descended from net.

I'd have to disagree with that. At least if we are to consider c++ a descendant of c, than calling c++/cli a descendant of c++ could certainly be valid while calling it a descendant of .NET really doesn't make any sense.

.NET is a common langage runtime, common type system, meta-data about assemblies and thier internals, etc. In a nut-shell you can consider .NET a virtual machine. While that is not at all acurate in the VMWare sense of the word, in the JVM sense its probably as accurate as can be without going into huge detail.

Anyway, the point is .NET is anything but a "language" like c, c++, FORTRAN, ect though .NET does include Common Intermediate Language (CIL), it is the equivelent to Java byte-code and not really a langange as a developer would think of it. Since .NET is NOTHING like c++/cli, I don't see how you can consider it a descendant of .NET.

Think about it like OOP. If an object B inherits from another object A than object B will have all the same properties, methods, etc as object A. Object B will have some extra stuff and may override some of the original objects stuff, but basically Object B is Object A with "extensions". In that sense c++ may be a descendant of c and c++/cli may be a descedant of c++ (but certainly not .NET).

Now perhaps a better name for this would be something like c++.NET as what these extensions mainly do is provide the c++ lanange (or at least MS's version of it) with an interface to the .NET environment and in fact I think that would perhaps be more clear and help resolve this situation. However, with MS calling everything xxx.NET perhaps they are trying to kick that habbit ;-)

Re:Plus Plus!

[Anonymous Brave Guy]

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."

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.

Re:Plus Plus!

[radtea]

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++.

Re:Sounds like a molehill masquerading as a mounta

[MBCook]

I saw this somewhere else the other day. The problem is not that they created this version of the language, but what they are calling it. If they called it "C++.Net" all over the place, no one would complain. Even if they called it "C++/CLI" which I think is a little more unwieldy for general use.

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.

ANSI

[NullProg]

ANSI C/C++; If your a .Net developer, don't use Microsoft C++ extensions/managed VM, But of course most c/c++ programmers know that already. Microsoft could/should call thier .Net VS5 hybrids something else besides C++. I'm suprised Bjarne Stroustrup hasn't said anything yet.

Enjoy,

So what?

[kclittle]

So what if MS tries to super-set C++ -- big deal! The industry as a whole has only been doing this to C for, oh, 30 years or so? Have you ever looked at list of advanced, non-standard features of "GNU C" (note the full name in quotes)? And I don't recall in which C compiler I first saw support for the end-of-line comment "//" (Vax C?), but is sure as hell was non-standard at the time. I don't recall any pulling of hair and renting of garments over that.

Re:So what?

[kclittle]

The point is, adding non-standard enhancements to C is a long accepted practice. Even when done by big, powerful companies. And, IIRC, no one considered it all that obnoxious, as long as it didn't break old code (i.e., was either a superset feature or could be controlled by compile-time options). It was competing, it was innovation, it was pushing the envelope. Now, all of a sudden, because it's MS, it's "news", it's "oooooooo, scary!". Baloney. This is just slashdot paranoia and/or bias at its worst.

Re:So what?

[mrchaotica]

...and all the C I write -- despite the fact that it only targets platforms with GCC -- gets compiled with the -ansi flag.

Re:Sounds like a molehill masquerading as a mounta

[slashdotnickname]

If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.

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 .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.

Re:Sounds like a molehill masquerading as a mounta

[Anonymous Coward]

So, I take it you're vehemently against EC++ as well?

You can't be too happy with those Boost guys, either, tampering with the purity of ISO C++ by adding library features.

Re:Sounds like a molehill masquerading as a mounta

[julesh]

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.

Re:Sounds like a molehill masquerading as a mounta

[Anonymous Coward]

5 You try to compile, and it fails horribly.
6 After some time spent debugging,

And now, back in reality:

5. You try to compile and it fails.
6. You spend seconds looking at the compiler errors and realise this isn't the C++ you know.

You could say the same about any library. eg. I get a linux C++ lib, compile it, link against the .so and it fails horribly. Gosh, imagine a C++ lib not being C++ in that case.

Or, if you have the source code (and not a library), you get a C++ lib, compile it and it fails.. because it contains (say) Linux signal handling code that Windows doesn't understand. Gosh!

You may get really pissed off but I hope you're only being annoyed at your own incompetence.

Good for PHBs, bad for maintaince programmers

[bensch128]

I think this naming scheme is bad for the C++ community as a whole because it creates the impression that code created using C++/CLI will be portable to other platforms and compilers. Of course, this is not true because after the initial programmer creates the "innovative' program using generics and managed pointers, the maintance programmer after him will find it impossible to port the code over to another platform without majorly refactoring the code.

Of course the initial programmer will love to use C++/CLI because it looks good on his resume and he can get a 50% pay raise when he jumps over to another job. The PHB loves it because he looks like he's using cutting edge technology to solve the company's problems. He too gets to put .Net on his resume to recieve that 50% pay raise. Everyone else loses.

Personally, I consider g++ to be the standard and I highly disrepect other compilers which can handle code valid for g++. Of course VC++ will be able to compile g++ code but the reverse is hardly ever true. (3.4.4 has been good, Im hoping 4.0.x will be better...)

Cheers,
Ben

Re:C++/CLI supports templates, people!

[Jeremi]

The only real C++ feature that isn't supported is multiple inheritance (with the exception of interface implementation). And that's just fine with me.

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++.