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.
That's clear. Look in VS 2005 and beyond. There is small or no support for many things involving C++/CLI. For instance you don't have the Class Designer, which is such a pitty (and there won't be in VS 2007 either). There isn't any support for C++/CLI as code-behind files with XAML (VS 2007), which is a bummer. And I can continue with the examples. All this shows that C++/CLI is only a second class language for Microsoft, and C# and VB.NET are the front runners.Quote:
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.
As an MVP I bet you'll be taking this up with Microsoft at the first opportunity...
However, it's nice to know that
(1) Microsoft are saying that C++/CLI is the language to go with if you want fast, efficient IL code.
(2) Actually no its not the best language to work in.
I know where Microsoft are coming from i.e. a business point of view rather than anything else. Or should I say supporting and considering the businesses that use their software rather than just dictating to them the way that they will do things.
Darwen.
There were a lot of questions about C++/CLI, present and future, in the slow chat. Frankly, I'm not very happy with the current commitment. It seems that we have to wait a while for the same support in the C++/CLI direction like with C#. ;)
I read that too. I can understand that there's little commitment to C++/CLI because C# is a so much better language. What I find strange, or rather sad, is that there's no commitment to unmanaged C++ and the MFC. The only promise was that it won't disappear anytime soon.Quote:
Originally Posted by cilu
My interpretation is: We want you to write C# programs but it's okay to throw in some unmanaged C++ when necessary. That's what MS fully supports.
You got that totally wrong. There is commitment towards MFC, which will be changed to suport Vista controls, in the next version of Visual Studio, code-named 'Orcas'.Quote:
What I find strange, or rather sad, is that there's no commitment to unmanaged C++ and the MFC. The only promise was that it won't disappear anytime soon.