Microsoft’s C++/CLI Language Specification is an ECMA Standard (ECMA-372) and they are trying to fast track this document to be an ISO standard. The problem is that the language specified is very different from C++ and so is likely to create a great deal of confusion. Details can be found in the UK objections [.pdf], which suggest that a name distinct from C++ be used for the proposed language.
It comes right at the end of the article:
This paper should not in any way be taken as suggesting that there is a sinister plot by
Microsoft or anyone else to usurp or subvert the C++ Standard. Microsoft is an active
participant in and a strong contributor to WG21. We accept that the people involved in
this project are sincere in what they are trying to accomplish and do have persuasive (to
them) reasons why they think these are good ideas. However, we also think they
misunderstand what is important to other people.
Obviously, that is the conclusion you come to after you have read the article, and remember the whole Visual J++ vs Java situation.
From what I understand after reading this document, Microsoft has made too many changes to the C++ language for it to be called C++/CLI. I personally think it is even worse than what they did to Java with Visual J++. At least, all they did back then was include some non-standard classes (i.e. WFC). Here, they’ve added new keywords, overloaded the meaning of existing keywords and changes the default behavior of inheritance in C++.
Nevertheless, the example in inheritance does make me ask the question, why bother with the new keyword interface? Surely you can define purely virtual functions in a struct? I fail to see why they would create a new keyword (just to be like Java/C#?) for such a feature that currently exists in C++.
The new keyword stinks
Call it Bob. Maybe a product with that name will have longer legs in the market this time around.
What do you do if your compiler isn’t following accepted guidelines?
1 – Spend millions fixing it.
2 – Have your implementation declared the standard.
Why am I not surprised MS chose #2?
They already have a C++ that follows the standard relatively well. What they are doing now is having a compiler for their modified C++ language… Which makes since. They needed to modify C++ so it could better support .NET. What’s wrong with creating a new language.. As long as they dont’ try to sell it as C++ and make sure they say it’s C++/CLI, what’s wrong with that?
Nothing is wrong with creating a new language which the objection clearly points out, but because the names are too similar confusion will arise:
Quote: Documentation for Microsoft’s Visual C++ product contains many code examples identified as “C++” –not “C++/CLI” or even “C++.Net” — which will fail to compile in a Standard C++ environment.”
So unless the name is changed to a less confusing one this may indeed be looked upon as selling an extended C++-language as ‘C++’.
You are not surprised because they’ve always done it that way
They KNOW they got much power, and guess what, they’re using it
MS’s latest attempt to mix C++ and .net is just slightly better than their previous laughable attempt that was totally rejected by the C++ community.
A language that has both generics and templates???
A language that adds “^” and “%” operators to go alongside “*” and “&”??? Yuk.
And context-sensative keywords? And keywords with embedded whitespace?
Yes, the author is right. Please don’t even call this doomed over-boiled syntactical soup C++.
“Please don’t even call this doomed over-boiled syntactical soup C++.”
Why? C++ also fits that definition perfectly… I guess Microsoft just wants people to be sure that their new C++ is just like the old one…
Jokes aside, if it isn’t C++, they shouldn’t call it C++. It’s as simple as that.
What’s the advantage of using this “thing” instead of C#? Performance?
It’s easier to migrate existing C++ code to C++/CLI than it is to migrate it to C#. There would be few willing to start new projects in C++/CLI.
> It’s easier to migrate existing C++ code to C++/CLI
> than it is to migrate it to C#.
I wouldn’t be too sure of that. The changes in the destructor and constructor semantics alone would drive any C++ to C++/CLI porter up the wall. This would be especially true if your app uses any MFC or STL. I’ve done C to C++ porting. From experience, subtle differences (like the implicit typedef definition of structs and the C++ ‘bool’ type) can be a lot more maddening than blatently different features (classes, templates, etc). With subtle differences, your code still runs but you get the wrong behaviour and it’s hard to recognize what’s wrong because the old code “makes sense”. With blatent differences, the compiler screams at you until you fix the problem.
Given the differences, to me it would make a lot more sense to either wrap your C++ code in a COM object and import that (.NET appears to integrate seemlessly with COM objects) or leave your pure C++ code alone and use .NET’s PInvoke to call it from C#.
Bastardized beyond recognition.
It’s more or less a superset of standard C++, and from what I’ve read it’ll still compile standard C/C++ code, so what’s the big deal? You don’t have to use the new “extensions” if you don’t want to.
That’s OK. The whole fuss is about not calling the new language so it can be confused with real C++ a it’s not much closer (given its intended usage practices) to C++ than to say C#.
The document explained why the confusion (which MS actually intentionally spurs) is hurtfull to C++ and beneficial to MS.
Besides some features in the language are syntactic sugar which are to lure C++ developers from the standard.
Generally it’s interesting if there’re means to stop MS from calling their hibrid languages what they aren’t.
It was no fun whatsoever trying to do the logic of an application using std::string liberally in C++, and then try to make it work with the managed code.
How is this any different from the situation with C vs C++ vs C#? There doesn’t seem to be much confusion between these languages despite similar names.
It is.
C is C both on Solaris, Linux, and Windows.
C++ is C++ both on Solaris, Linux, and Windows.
Microsofts version of C++ on CLi is not the same as C++ anywhere else, hence there’s a great difference to your example and C++/CLI should be called something else like ‘Foo’.
I have to agree with the UK document. The changes are significant and reasons behind the changes are less than legit.
It is.
C is C both on Solaris, Linux, and Windows.
C++ is C++ both on Solaris, Linux, and Windows.
Microsofts version of C++ on CLi is not the same as C++ anywhere else, hence there’s a great difference to your example and C++/CLI should be called something else like ‘Foo’.
C++/CLI is C++/CLI everywhere it’s implemented which is why there’s a standard. It isn’t purporting to be the same as C++, hence the name change. If it was just C++ on the runtime, they wouldn’t have bothered with the new designation.
You’re missing the point of my original assertion. The PDF’s assertion is that C++/CLI is confusing because it adds keywords and constructs yet keeps a similar name. The same can be said of C++ in relation to C. The situation is no different.
Italics from the PDF:
Possibly the largest faction of C++ programmers in the world are working mainly with
Microsoft’s compiler and platform. To them, Standard C++ is what Visual C++ does. If they develop expectations that “C++” now has these new features, whether or not those expectations are accurate, it will place at a disadvantage all competing products which offer conformance merely with Standard C++. Portable programs will be disparaged for not taking advantage of platform-specific extensions available only in the Windows environment.
This is the same lame excuse that was used for Java, basically implying that programmers are too stupid to code to the C++ standard even if that’s what they desire. If you really expect programmers to be this dumb, then there must be a lot of programmers out there writing Win32 and MFC code just because they believe it’s standard, portable code because Visual C++ lets them write it.
(There is an open source implementation of CLI for other systems, called Mono, but to our knowledge currently no other compiler in the market supports C++/CLI.) The objective of using Standard C++ to achieve portable programs will be completely undermined.
So just because there is currently no alternative implementation that they know of, C++/CLI is supposed to be criticised even though nothing would stop a third-party from implementing ECMA/ISO C++/CLI just as nothing stops anyone from implementing other ECMA/ISO standards. With this logic, no one would implement any standard as long as only one entity bothered to come up with an implementation.
Edited 2006-01-30 03:47
I am sorry to say that I do agree with this critism; there are a lot of programmers that do not know how to code. A lot of Microsoft programmers are IDE monkeys. They know how a wizzard works, but they do not know how to code. They expect that the IDE will do a lot of thing for them. And don’t get me started on Visual Basic programmers….
C++/CLI is very closely ISO standard C++ compliant. When you program in native mode, you use the ISO C++ language. Only when you target the .NET framework will you use the extensions, which indeed differ quite a bit from C++. However, the .NET runtime itself uses such different idioms that it’s impossible to program it in ISO C++. Microsoft had to extend the C++ language to adapt it to the CLI. The native part of this new language is highly comformat ISO C++.
The goal was to make a language that’s 99.99% ISO C++, compiles most existing C++ code, and by introducing extensions, it can be hooked up to the .NET environment. If you find it odd, you can blame the .NET framework itself for everything, and not the language. For example, the lack of const member functions, the lack of destructors, and so on, are all problem in the CLI, not in the language, and C# suffers from the exact same problems too. C++/CLI does its best attempt to bridge between native ISO C++ and the .NET framework.
Yes it has both generics and templates. They are very different concepts. Template is a compile time paradigm, it makes it possible to generate code at compile time. It’s much more powerful than a generic, because it supports metaprogramming, writing programs that run at compile time. Those who think that templates are merely a way of writing generic min, max functions and containers have an incomplete understanding of templates and the power they have. Templates are turing complete, generics are not.
On the other hand, generics have advantages too. They can be pre-compiled, you don’t have to provide the source code for your generics. If you want to make your library work on the rest of the .NET languages (C#, VB.NET, etc.), you must use generics, not templates. So they’re both valid idioms, they both have their own place.
C++/CLI is the best language to wrap native C++ code into .NET assemblies. You can think of it as wrapping your native libraries to COM objects. C++/CLI is also excellent when you want to mix native and managed code. C++/CLI is the mainstream .NET programming langauge, the only Microsoft provided language that supports all features of the .NET framework. However, you can choose to use it only for interfacing native code with C#.
It’s the biggest misconception that Microsoft has a non-conformant language that they want to call C++ and standardize it.
Now, I’m as much a fan of C++ as anyone else, but intentionally obfuscating the language even more?!
That, my friends, is a real tragedy.