|
Kant wrote:
I haven't jumped into the MC++ or C++/CLI bandwagon. But Is C++/CLI the new buzzword which replaces MC++?
The old syntax (the one that came with VS.NET 7/7.1) was called MC++ (Managed C++ or Managed Extensions to C++), and the new syntax - the one that will ship with VS 8 is called C++/CLI. So basically if someone says MC++, he means old syntax and if he says C++/CLI, he means new syntax. But I think this is still a little confusing and it's safer to say old syntax and new syntax [even though I personally think, that's sorta confusing too].
C++/CLI does not really replace MC++, rather it improves on it.
Nish
Now with my own blog - void Nish(char* szBlog);
My MVP tips, tricks and essays web site - www.voidnish.com
|
|
|
|
|
Thanks for the clarification. In my current project, the client decided to rewrite the COM+ (VC++) components in C#.
In my view, even the companies are confused with MC++ (__gc) or C++/CLI lingo. IMO, I see very little growth in MC++/C++/CLI area, as the companies (except for the financial firms) stopped developing new projects using VC++.
It took 2 years for Microsoft to realize their mistake(Was that intentional?) with MC++, by that time most of the companies who decided to jump into .NET bandwagon, choose C#.NET for their new projects.
Promise only what you can do. And then deliver more than what you promised. This signature was created by "Code Project Quoter".
|
|
|
|
|
Unfortunately, I must agree with this I see too many stories about switching from C++ to C#. There are two main reasons for this IMHO:
1) Marketing reason. I attended 2 MS-organized .NET events in 2001, and in both of them they mentioned MC++ as a "transitional technology", and "not a first class citizen in .NET world". Practically all the samples for .NET technology were written in "both VB.NET and C#". And remember the diagrams suggesting that VB6 programmers should switch to VB.NET and C++ and Java programmers to C#?
2) Technical reason. C++ is the most complex among popular programming languages. Becoming a competent C++ programmer requires years of practice and learning, and there are very few people who can claim to know C++ 100%. Now, with MC++ and C++/CLI we have an already complex language squared into a totaly different object model ("cosmic hierarchy", reflection, no MI, ...) which in effect means that to be a competent C++/CLI programmer one needs to be familiar with both object models. Not to mention that we have both generics and templates in C++/CLI - a competent C++ programmer will be required to understand both: how they differ, what are they good for. For experienced C++ programmers it may not be a big deal, but how many youngsters would be ready to go this path?
|
|
|
|
|
I think those reasons were valid to date, although they are changing.
1. At TechEd this month, overall throughout all talks you will see as many code examples in C++ as in C#. In the Whidbey timeframe (which is going into beta this summer), C++ is a first class citizen in .NET and the Microsoft-recommended language for applications that have an existing C++ code base (which can move forward and incorporate .NET features where/as they like essentially seamlessly) and applications that call unmanaged libraries (which is typically 50% faster than C#, and much easier in code as in C++ you just call the function without special setup and it just works).
2. With the C++/CLI extensions, using .NET types and features is as easy in C++ as C#, usually with nearly identical syntax. If you want to write pure brand-new .NET applications only, you can write in the C++/CLI (or "C#" ) subset of C++ and get pure verifiable code as easily as in C# or VB. And there are real reasons to choose C++ even on the home turf of pure .NET languages:
1. Deterministic destruction: easier to program, no Dispose pattern or using blocks.
2. Performance: Often the C++ equivalent code will run 25% faster because C++ code goes through the C++ front-end and heavily optimizing back-end which results in better IL than C# (because C# does nearly no optimization in the compiler and relies on the JIT for its optimization; of course, the JIT needs to be fast, and so doesn't do heavy optimization).
Cheers,
Herb
|
|
|
|
|
Hi, Herb:
It sounds great!
I just love C++. I use C# sometimes, but it doesn't make me very happy. Unlike C++, C# is poor in performance and flexibility.
I think that any application from C# may be professional at most but never be world class.
Cheers
Charlie Ye
|
|
|
|
|
Herb Sutter wrote:
At TechEd this month, overall throughout all talks you will see as many code examples in C++ as in C#. In the Whidbey timeframe (which is going into beta this summer), C++ is a first class citizen in .NET and the Microsoft-recommended language for applications that have an existing C++ code base ...
I am really happy to hear that. However, will it bring back the developers who already switched to C#? We (VC++ community) have lost 3 years as "second class .NET citizens" or even "dinosaurs". Can we revert back all the damage now?
Herb Sutter wrote:
Deterministic destruction: easier to program, no Dispose pattern or using blocks.
I love deterministic destruction, and while I am not sure that calling Dispose under the hood is the best possble way to achieve it, it is still much better than the mess with finally and using .
Herb Sutter wrote:
Performance: Often the C++ equivalent code will run 25% faster...
This is good, but frankly, for performance critical code I will stay away from .NET. The great thing about C++ in this regard is the possibility to make mixed assemblies.
|
|
|
|
|
With Longhorn widely using managed code, it's seem very important to provide a langage optimized for OS programming. It push new limits to managed code.
Microsoft knows that even if C++ is a long leaning curve langage, it permits efficient coding in a mixed environment (managed and unmanaged). MC++ was technically good but ugly to program. C++/CLI is a good refresh (neither __gc nor gcroot<>) with invaluable novelty (deterministic destructors, ...).
Even if Microsoft folks can work with MC++ ugly syntax, C++/CLI refresh was needed for all of us to cope with it. And Microsoft knows too that they can't develop an internal langage. It's better to share the langage with others. It can earn money, help to improve stability and move away trials (joke). So they provides us C++/CLI.
Yes, this is not pure Ansi C++. We can't simply download and have it to compile. But it can smooth transition. It could permit me to develop libraries targetting both world managed and unmanaged. But i need it now. Not in "more than one year". With a such long wait, only Microsoft wins. They have a community to help to improve C++/CLI, they can use it internally for Longhorn, but we can't use it. We can't start a project using a langage without knowing when this langage will hit the street and what will be in the box. Microsoft can decide (for somme Longhorn reasons) to remove such or such feature.
Whitbey delay let's me angry.
|
|
|
|
|
Got my 5
Y'know, this just might make me change my mind about using managed C++. The __gc style syntax was just ugly enough to make me shy away from it.
Rob Manderson
Colin Davies wrote: I'm sure Americans could use more of it, and thus reduce the world supply faster. This of course would be good, because the faster we run out globally, the less chance of pollution there will be. (Talking about the price of petrol) The Soapbox, March 5 2004
|
|
|
|
|
Rob Manderson wrote:
this just might make me change my mind about using managed C++
I have to agree with that. I just got small project dumped into my lap that was windows based. Last windows project I had ( in 2002 I think) I decided to try learning MC++ but bailed as the learning curve seemed beyond the timeframe that would allow to also complete my project.
anyways, good article
---------------------------------------------
It's amazine how simeple life can be when one get's his head out of his ass...embly
If they don't get the basic research and learning skills down then they'll end up having a very hard life (Either that or they'll become managers) - Micheal P Butler
|
|
|
|
|
I also agree.
Rob Manderson wrote:
The __gc style syntax was just ugly enough to make me shy away from it.
Managed extensions semmed - in fact - a "brute force add" that was required to let C++ programmers to be able to access .NET libraries (they seems all thoghts by a "C# brained").
Now we can finally see a more mature approach: new functionalities are available, interact with old ones, but doesn't confuse it and make old code trying to behave as new code.
Poiters are pointers, handles are handles.
It is not clear - however - what happens to other stuffs like "multiple inheritance" (abd virtual inheritnace and dominance and ...) lot of other C++ speciality that appeare to be suppressed in .NET
|
|
|
|
|
Excellent article!
Matt Newman
All rise for the honorable Judge Stone Cold Steve Austin - From Dilbert Episode 30
|
|
|
|
|
First of all, thanks for a good article. It has my 5.
Having said that, I would like to comment several points you made:
All those ugly double underscores are gone now.
Underscores may be "ugly", but they are ISO C++ Standard compliant way of adding additional features to the language. Keywords like ref are not.
The MC++ compiler could not produce verifiable code
It can[^] although it is not really an easy thing to do.
Confusing pointer usage - Both unmanaged C++ pointers and managed reference pointers used the same * based syntax which was quite confusing because __gc pointers were totally different in nature and behavior from unmanaged pointers.
While I agree with this, it is very easy to get around this problem. If you look at my MC++ articles, you'll see that I use * only for pointers, and for managed references I use __gc * . Sure, it would be better if compiler forced this kind of behavior, but my point is that it is still possible to write "non-confusing" MC++ code
Boxing is implicit (yaay!)
I wouldn't be sure about this "yaay!". Implicit boxing can be a source of subtle bugs, and it requires programmer to track which variables get boxed, and which not. I am lazy, and prefer compiler to do it for me
One thing I really like about C++/CLI is deterministic call to Dispose - something I really miss with C#. However, I have mixed feelings about this new syntax. I've written a lot of "__gc" code, and now I feel a little betrayed. Did I just waste my time learning MC++? How am I going to sell the idea of using C++/CLI to my management if Microsoft deprecates its technologies after a couple of years?
Anyway, thanks again for the good article.
|
|
|
|
|
Hello Nemanja,
Nemanja Trifunovic wrote:
Underscores may be "ugly", but they are ISO C++ Standard compliant way of adding additional features to the language. Keywords like ref are not.
Yeah, agreed. But the underscores kept reminding everyone that the managed extensions were just those - extensions, and not really a first class .NET language. Keywords like ref might be breaking the standard, but that's where the ECMA proposal sounds good in the sense that C++/CLI will eventually be a recognized standard that other compilers might support too.
Nemanja Trifunovic wrote:
Implicit boxing can be a source of subtle bugs
True, but I used to get really annoyed by having to use __box all over the place, and specially in my Console::WriteLine 's
Nemanja Trifunovic wrote:
I've written a lot of "__gc" code, and now I feel a little betrayed. Did I just waste my time learning MC++? How am I going to sell the idea of using C++/CLI to my management if Microsoft deprecates its technologies after a couple of years?
I understand your feelings, you should read this blog entry of mine :-
To C++ or not to C++, that is the question!
Nemanja Trifunovic wrote:
Anyway, thanks again for the good article.
Thanks you.
Regards
Nish
Now with my own blog - void Nish(char* szBlog);
My MVP tips, tricks and essays web site - www.voidnish.com
|
|
|
|
|
Nishant S wrote:
But the underscores kept reminding everyone that the managed extensions were just those - extensions, and not really a first class .NET language.
Removing underscores and introducing ref is not going to make C++ a first class .NET language. It is just targeted towards a different environment, and introducing new keywords is not going to change it. Stan Lippman in his blog[^] describes this issue very well. It is just a different beast. C# is a first class .NET language, and when (if ever) it gets all the features I need, I will probably use it for "pure .NET" programming. Managed C++ is about reusing the huge C++ code base - not about developing typical ".NET applications".
Nishant S wrote:
I used to get really annoyed by having to use __box all over the place
It comes to "readability" vs "writeability". Personaly, I prefer to spend more time writing code that would be easier to read, than vice-versa (otherwise, I would be using Perl all the time ).
Nishant S wrote:
you should read this blog entry of mine
I did. It is great, but it does not offer the solution to my dilemma: How do I expose the functionality of my existing C++ libraries to .NET world? MC++ is great for it (well, it would be if it was a little less buggy) but it is going to be deprecated soon. Whidbay is a year from releasing, and the customers want .NET interface now. The only solution I see is to keep using MC++ until VC++ 8.0 is released, and then convert all "__gc" code to "ref" code. Somehow, I don't like the idea
|
|
|
|
|
May be if the whole blog thing was happening like it is now when MS designed MC++ may be they would have thought twice about bringing it out, I guess the C++ team had to do more work on their front to grok the c++ compiler emit managed code.
Nemanja Trifunovic wrote:
I prefer to spend more time writing code that would be easier to read,
I'm sure _underscore__ dont help much in improving readability I hate underscores in the code and stayed away from MC++ just for that reason, forget the underscores I'm sure you must have come across the first level/second level access specifiers.
Apart from these, the plumbing one needs to do again and again on converting strings and pointers is too frustrating. Anyway, I'm sure MS just came with MC++ as a stop gap thing, 'cause if there is a problem with MC++ MS would've known that long before we complain just by sheer no. of c++ geeks inside the company.
Anyway, its good that finally they are taking this step towards standardisation may be Mono in future would boast a c++/cli compiler or Intel would release their own, earlier this was difficult cause it was not standardised.
Regards,
Kannan
|
|
|
|
|
Kannan Kalyanaraman wrote:
I'm sure _underscore__ dont help much in improving readability
I was refering to implicit boxing, not the underscores.
BTW, I really don't understand all this "anti-underscore" sentiment. Is it such a big deal?
|
|
|
|
|
Nemanja Trifunovic wrote:
Stan Lippman in his blog[^] describes this issue very well.
BTW, regarding implicit boxing, Stan has been rather evasive. I mean, he has said that implicit boxing is quite fine and that the older explicit boxing was rather annoying and meaningless etc. But he has not really laid out any solid points for why implicit boxing is technically an improvement - in my personal case, I just feel that implicit boxing is so comfortable to use, and in any case, with the old syntax, whenever there was a need to box a variable, I just boxed it without thinking further, so the fact that it's done automatically for me is not going to change many things.
One funny side-issue though. Whenever I had given a talk on MC++ in the past, one point I stressed on was that it gave us a lot of flexibility and power and specifically mentioned explicit boxing as an example of that; now I wonder how I will tell the same audience that the new syntax has improved over the old one by giving us implicit boxing!
Nish
Now with my own blog - void Nish(char* szBlog);
My MVP tips, tricks and essays web site - www.voidnish.com
|
|
|
|
|
Underscores may be "ugly", but they are ISO C++ Standard compliant way of adding additional features to the language. Keywords like ref are not.
You might be interested in
http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx.
As Herb points out, C++/CLI only adds 3 new reserved words, and ref isn't one of them. One of those 3 (nullptr) already has the blessing in principal of the C++ committee (they're going to add the same keyword with the same meaning to C++0x).
...I have mixed feelings about this new syntax. I've written a lot of "__gc" code, and now I feel a little betrayed. Did I just waste my time learning MC++? How am I going to sell the idea of using C++/CLI to my management if Microsoft deprecates its technologies after a couple of years?
Two points: First, the old syntax will continue to be supported. Second, this is precisely why the new syntax is being standardized by ECMA - to demonstrate and ensure long-term commitment to this syntax.
|
|
|
|
|
Hey Carl,
I didn't know you hung around on CP
Carl Daniel [VC++ MVP] wrote:
http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx
Yup - had read that a while ago, but spaced-keywords or not, truth is that for non-Windows coders, looking at C++/CLI code will be a bit baffling initially
Carl Daniel [VC++ MVP] wrote:
First, the old syntax will continue to be supported
I think the support is only for Whidbey and not for Orcas. Anyway I don't think anyone should be encouraged to continue coding using the old syntax anymore.
Regards
Nish
Now with my own blog - void Nish(char* szBlog);
My MVP tips, tricks and essays web site - www.voidnish.com
|
|
|
|
|
Although the link doesn't work (at least at the time I am reading this), I read all Herb Sutter's blogs, and I am pretty sure I know which one you mean.
Yes, you are right - ref is not a new keyword - ref class is. However, I don't see how this makes any difference. It is still not compliant to ISO Standard.
The real reason for deprecating underscores can be found in another Herb Sutter's blog[^]:
For one thing, programmers have complained loudly that all the underscores are not only ugly, but a real pain because they're much more common throughout the code than other extensions such as __declspec have been. In particular, __gc gets littered throughout the programmer's code.
At least as importantly, the __keywords littered throughout the code can make the language feel second-class, particularly when people look at equivalent C++ and C# or VB source code side-by-side. This comparative ugliness has been a contributing, if not essential, factor why some programmers have left C++ for other languages.
However, I would agree with a comment from Edward Diener (the same blog):
I believe it is a mistake to drop the __ extension format because you think it is ugly. It is the accepted way to add keyword syntax extensions to C++, and clearly shows that the keyword is not a C++ standard one. Needless to say it also minimizes clashes with identifiers and macros. Some of your comments above regarding this are just plain silly: "Oddly, numerous programmers find the former more attractive. Particularly after the 2,000th time they type __gc." So they type 'ref' 2000 times instead. What a big improvement ! For properties: "property int Length { int get() { return len; } void set( int i ) { len = i; } }" As if: "__property int Length { int get() { return len; } void set( int i ) { len = i; } }" would somehow be horrible instead ! Finally your initial comments about ugliness, and C++ programmers leaving MC++ for other .NET implementations because of it, is really absurd. Nobody is buying that sort of argument, as if a computer language is a popularity contest in aesthetic appreciation.
|
|
|
|
|
Nemanja Trifunovic wrote:
[ Edward Diener ] :- Nobody is buying that sort of argument, as if a computer language is a popularity contest in aesthetic appreciation.
LOL - But truth is that not everyone who codes in C++ does it out of choice. Some people might be forced to do C++ because a current project requires it of them - typically a bug-fix project or a version upgrade. Now these are usually guys used to Java and C#, and obviously they'd feel that C++ code looks sort of ugly.
And personally I have heard at least 20 programmers tell me that they found MC++ ugly and artificial - and most of these guys are VC++ guys of 4-5 years experience - so we are not talking of Java/C# people here.
Nish
Now with my own blog - void Nish(char* szBlog);
My MVP tips, tricks and essays web site - www.voidnish.com
|
|
|
|
|
Nishant S wrote:
And personally I have heard at least 20 programmers tell me that they found MC++ ugly and artificial
Me too. However, I am not sure that underscores are the main reason for this - although it is the first thing they point to.
I think that most of VC++ programmers will fall into one of these categories:
1) Diehards - they will stick to unmanaged C++ and libraries like WTL, MFC, ATL, STL, Boost... If MS really leaves out the unmanaged API from Longhorn (which I don't think will happen) they will probably switch to Linux.
2) .NET converts - most of them will switch to C# (many already have).
Personally, if I have a choice, I would like to write the bulk of my code in ISO C++, and then write C++/CLI "facade" classes to expose the functionality to .NET world.
|
|
|
|
|
Hi, Nemanja:
I agree with you.
"Personally, if I have a choice, I would like to write the bulk of my code in ISO C++, and then write C++/CLI "facade" classes to expose the functionality to .NET world."
Simply speaking, I don't want to write a sluggish application. C++ is the only language to free my brain. It permits me to achieve a goal with my own ideas instead of any others
|
|
|
|
|