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

Various corrections and more information.

[jdennett]

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

Re:Sounds like a molehill masquerading as a mounta

[SnprBoB86]

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.

"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 .NET brand) IS STILL C++

Re:ANSI

[kupci]

As a matter of Stroustrup has commented. In a nutshell, he says that Microsoft is revising their documentation to minimize confusion.

Link to Groklaw

[kupci]

Some additional detail with good comments on this subject available over at Groklaw.

Stroustrup's comment. Apparently Microsoft is revising their documentation to clear up the confusion.

Re:So what?

[Anonymous Coward]

Here's the problem.

First, C++ / CLI is not compatible with C++. It's not even close. It's not a strict superset of C++, so old programs might behave differently under C++ / CLI, in much the same way that C programs can behave differently when compiled as C++. They aren't really the same language.

Second, Microsoft are misrepresenting C++ / CLI as standard C++. Their tools and their documentation lead people to believe that C++ / CLI is actually C++.

The problem is not that Microsoft have come up with an extended version of C++. In fact, C++ is an extended version of C, as is Objective-C, and there are a couple of other languages derived from C++, like Embedded C++. The problem is that they're calling it C++, when it's really quite different.

I'm glad people are complaining about this.

[alyosha1]

I've already been bitten by this - I wrote a perfectly short C++ program as a tutorial for a friend, using VC++ 2003, but when he tried to compile it on VC++ 2005 it gave this warning:

warning C4996: 'std::_Transform' was declared deprecated

which implies, at least to the novice developer, that the use of the standard c++ algorithm library is no longer considered appropriate practice. This is extremely annoying and misleading. One of the major strengths of C++ is that you can extend it almost limitlessly without changing the underlying language. As far as I can see, for every extension that people have tried to add to the language to support a particular paradigm, it has been shown that the same effect can be achieved without going beyond the bounds of the language.
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.

Boys, boys, calm down.

[hummassa]

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)

Re:So what?

[MooCows]

I don't know much about C++/CLI, but this is different from what I've heared before (of course what I've heared before may be wrong). Could you please post a valid C++ program which would behave different under C++/CLI?

Well, as far as I know any C++ code compiles just fine in with C++/CLI extensions enabled.
Just last month I wrote a C++/CLI wrapper class for a large C++ codebase so our .Net applications could link up with it. No code in this substantially large library had to be altered so it could compile in C++/CLI. The C++/CLI extensions are only needed to interface with .Net.
Also note that the code was originally 'written for' GCC++. :P

So for example, take this pseudocode:

String^ GetText(int index)
{
char* ctext = myNativeLibrary->GetText(index);
String^ text = gcnew String(ctext);
delete[] ctext;
return text;
}

The method GetText can now be called from any .Net application, and will return the .Net type String. Everything in myNativeLibrary is just plain old C++, without garbage collection or .Net library support.

Short answer: no.

[hummassa]

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

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

[Jeremi]

Sure you can, you'll just have to continue compiling it as regular c++, with an c++/cli interface layer if you want to access it from .net.

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