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

It's all in how you read it

[smittyoneeach]

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.

Sounds like a molehill masquerading as a mountain

[BadAnalogyGuy]

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.

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.

On the one hand, you've got Microsoft who is willing to label various related products under one brand (Windows, .Net, etc) and on the other hand you've got a group who is relatively unwilling to give Microsoft the time of day.

I'm not saying that ISO's wrong, but they could certainly stand to pull that rod out of their collective asses.

Interetingly

[Utopia]

The prominent C++ expert Herb Sutter is the lead architect of C++/CLI.
He also chair the ISO C++ standards committee.

Re:Sounds like a molehill masquerading as a mounta

[mrchaotica]

How could you not be confused by it? Here's the sequence of events:

1. You're working on an ISO C++ project
2. You some particular functionality, so you search for it on the Internet.
3. You find a library that seems to do what you want at MSDN.
4. It's labeled "C++" (not "C++/CLI" or ".NET", just plain old "C++").
5. You download it, figure out the API (i.e. look at documentation, not the code itself, so you don't see the weird syntax), and integrate calls to it into your code.
6. You try to compile, and it fails horribly.
7. After some time spent debugging, you finally notice that it isn't normal C++ like it said it was, it's actually some kind of proprietary extension that you can't use.
8. You get really pissed off because you just wasted several hours.

Re:I'm glad people are complaining about this.

[ardor]

Actually, Qt signals can not be achieved by template-based signals, since Qt signals allow limited introspection, which is impossible with template-based ones. This comes in handy when serializing signal-slot-connections, for example.

Re:Plus Plus!

[angel'o'sphere]

This is completely wrong.

C++/CLI might be the name of the standard, what it means is: having a standard that defines how C++ is compiled to .NET byte code and executed in the .NET FrameWork.

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 .NET System Classes like System.Int32 etc.

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 .NET) like threading etc. and finalization has to have a counterpart in C++/.NET which is defined in C++/CLI.

a typical C++ clas in .NET mitght look like:

public class __gc MYClass {
      !MyClass() { ... } // finalizer - called after/during GC
      ~MyClass() { ... } // destructor (like in standard C++)
      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 ... I could imagine tehy are only generics, but I think they are still templates like in Visual C++).

If you need to write new code in .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!!

angel'o'sphere

Re:Sounds like a molehill masquerading as a mounta

[Anonymous Brave Guy]

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.