Whats the difference between C++/CLI and Managed C++?
Printable View
Whats the difference between C++/CLI and Managed C++?
Syntax mainly - however C++/CLI it is a standard (I believe) whereas Managed C++ is not.
Darwen.
Yes, it is a standard under ECMA (European Computer Manufactures Association) since late autumn 2005. Microsoft is currently looking for standardization under ISO.
In which way is it a standard? I mean C++ is standardized already. Does CLI add syntax to C++ which makes C++/CLI a dialect that's no longer compatible with standard C++?Quote:
Originally Posted by cilu
No. C++/CLI is a different language, based on C++, but providing support for the CLI.
I wrote an introductory article to C++/CLI here. It would be good to read it, especially if you have some .NET familiarity.
It looks like a bastardisation of C++. Who would ever want to use that? Are people expected to program in it directly or is it some kind of intermediate language used in automatic translations?Quote:
Originally Posted by cilu
Please don't tell me Visual C++ .NET programming using managed code in fact means using C++/CLI?
Well, "VC++.NET" name was a mistake from Microsoft, because it can lead to confusion. As a result, it with the release of Visual Studio 2005, the .NET part was removed from the name.
In VisualC++ from Visual Studio 7.0 and 7.1 you can write C++ programs (aka native applcations or MC++ programs (aka managed application). MC++ stands for Managed Extensions to C++.
In VisualC++ from Visual Studio 8.0, the MC++ langage was replaced with a new and better one called C++/CLI. However, compatibility to the former MC++ language is assured (by using a compilation switch). Again you have the two coinces, building native or managed applications, as well as mixed-mode applications.
C++/CLI is not a bastardization of C++. And if you want to leverage the power of the .NET framework, you have to use a managed language, and if you are a C++ programmer, you may rather want to use C++/CLI than C# or VB.NET.
I have said, and will continue to say, that the language of choice for .NET programming is C#.Code:It looks like a bastardisation of C++. Who would ever want to use that? Are people expected to program in it directly or is it some kind of intermediate language used in automatic translations?
However (as in fact I have been doing over the last 4 months) there are reasons for using C++.NET or C++/CLI.
I must say that the C++/CLI extensions are far more intuitive than their predecessors (the inclusion of a foreach statement is very welcome).
However you must bear in mind that native C++ and C++/CLI are two completely seperate languages.
Native C++ compiles down to native code, on whichever platform you are working on.
Managed C++ or C++/CLI compiles to IL code which is JITted (and if you don't know what this is look it up on google).
These are two completely seperate paradigms, one being the evolution of the other.
To say that one "bastardises" the other is completely wrong. Each have their place in modern programming, and each should be used according to their advantages and disadvantages.
But, when in doubt use C#. And use interop to interact with native C++ code (in the form of dlls, be it static Win32 dlls or COM dlls).
That's my preferred route of doing things.
Darwen.
If C++ and C++/CLI are completely different languages then you must admit that the name of the latter is a misnomer. If you develop a new language that isn't C++ then at least you should have the decency to call it something that doesn't give the impression it is C++.Quote:
However you must bear in mind that native C++ and C++/CLI are two completely seperate languages
To say that one "bastardises" the other is completely wrong. Each have their place in modern programming, and each should be used according to their advantages and disadvantages.
To me C++/CLI, regardless of its technical merits, seems like an attempt to lean on the credibility of C++ and to motivate that the "C++" letter combination still can be used in the Visual C++ product name.
Well if C++/CLI really isn't C++ and if C# is equally efficient in every possible way then why not prefer it. Is there a downside of using C# over C++/CLI?Quote:
But, when in doubt use C#. And use interop to interact with native C++ code (in the form of dlls, be it static Win32 dlls or COM dlls).
That's my preferred route of doing things.
I suppose and your father have the same surname. Are you the same person? Or do you think you two should have both first and last name differ to be two different persons? Do you understand where I'm going?Quote:
If C++ and C++/CLI are completely different languages then you must admit that the name of the latter is a misnomer. If you develop a new language that isn't C++ then at least you should have the decency to call it something that doesn't give the impression it is C++.
C++ is built based on C. Most of the things in C are present in C++ (some of them with changes, like the structs). But C++ and C are not the same language, because C++ has a lot of additions.
C++/CLI is built based on C++. EVerything from C++ is present in C++/CLI. But C++ and C++/CLI are not the same language, because C++/CLI offers extensions for the CLI.
To answer the last question, Microsoft now considers C++/CLI the most powerful language targeting the CLI.
So C++/CLI is a superset of C++? Well that improves the situation somewhat.Quote:
Originally Posted by cilu
http://msdn.microsoft.com/msdnmag/is...C/default.aspx
Although I'm not the only one who's reacted negatively to the name,
http://www.research.att.com/~bs/uk-objections.pdf
Have they said why? I'd guess to call unmanaged C++ wouldn't be any faster than doing it from C#.Quote:
To answer the last question, Microsoft now considers C++/CLI the most powerful language targeting the CLI.
Read this article: C++: The Most Powerful Language for .NET Framework Programming.
Additionally, you should read Stanley Lippman's MSDN Magazine Articles.
I referred to an "objections" link in my previous post. They warned for the possible confusion between the C++ and C++/CLI languages.Quote:
Originally Posted by cilu
Interestingly the title of the article you recommend is an argument in case. You get the impression that C++ is the most powerful .NET language. It's not, C++/CLI is, a totally different language.
I'll never buy it. C++/CLI is fool's gold. If I'm going to use .NET it's going to be C#.
Read the "objections" document. Here it is again,
http://www.research.att.com/~bs/uk-objections.pdf
I will have to say I've just spent 4 months writing an application in Managed C++, and boy was it hard work.
I know that C++/CLI is easier - the inclusion of a foreach statement is possibly the greatest improvement, but I believe (and Cilu will correct me if I'm wrong) you still have to do dynamic_cast etc and it's just so much easier in C#.
I think that instead of the code taking 4 months to write if I was able to use C# it'd probably have taken 1 month. As well as have been easier to read.
I'm not a fan of either managed C++ or C++/CLI, mainly because I find the number of keystrokes necessary to get something done is significantly greater than in C#.
Actually I find it funny that Microsoft have changed their views like this - C# was and still is the first .NET language and is designed from the ground up to be a .NET language. C++/CLI is still an extension of C++, no matter what anyone says, and is confusing if you don't know exactly what you're doing.
It is probably faster than C# (because of whole program optimisations etc) but I'd be surprised that it was significantly faster. Again Cilu could correct me on this.
However the ease of use of C# as opposed to both the .NET C++ derivitive languages far outweights any speed improvement in my opinion.
I still say use C# with native written in C++ dlls.
I've always found C# a lovely language to deal with. Both managed C++ and C++/CLI just seem like banging my head against a brick wall in comparison.
My personal opinion of course, so please no flames.... :)
Darwen.