tags:

views:

1044

answers:

8
+8  Q: 

Is C++ .NET dying?

I heard somewhere that Microsoft will be focusing their efforts on C# rather than C++ for the .NET platform. I can see signs of this being true because of the GUI designer that was available for C# but not C++.

So I would like to know if C++ in .NET is dying and if it will continue to be second to C# in the future.

+1  A: 

i think YES , its dying , actually it already died ;) , coz there arent lots of people who use it , they use whether c++ or c#. see this

Adinochestva
"Yes", yes what? "Yes it's dying"? Please make it clear.
Stefan Steinegger
yes its dying, i edited my reply
Adinochestva
+6  A: 

Managed C++ never really got to be what MS thought it would be. C# could do (nearly) the same thing, with a lot more intuitive and user-friendly syntax.

Apart from that, C++/CLI will not be left unsupported for a long time, as it's the easy way to create interop between .NET assemblies and native C++ assemblies. That's about all it's used for though (I'm sure there's a 0.001% of C++/CLI developers out there who disagree :P ).

cwap
So are you saying that you can't do interop between C# and native C++? I thought the p/invoke thing is entirely usable in C#
Unknown
@Unknown he's not saying you can't, he's saying "C++/CLI is the easy way". I don't know if I'd agree, though, because nothing in C++/CLI looks easy to me.
Daniel Daranas
C++/CLI is surprisingly easy... at least, compared to the re-writing the SDK headers from scratch necessary to use P/Invoke.
Shog9
+17  A: 

If you are targeting the .NET framework in application development then yes C++ CLR is a second class citizen compared to C#. C# was specifically designed as the language for .NET framework meanwhile C++ CLR extension is there to allow developers to bridge native and managed code.

However do not confuse C++ with C++ CLR (C++ .NET is the same thing...). C++ is alive and well in areas such as the kernel, games, high-performance and server apps (e.g. SQL server) all of which are unlikely to change. On the other hand most .NET 'GUI stuff' won't use C++.

Serguei
I didn't know you could access the framework with native C++ (is that why you say it is the same thing as C++ .NET?).
Unknown
He's saying "C++ CLR" is the same thing as "C++ .NET"
sharkin
You need to give the /clr flag to the C++ compiler if you want to use managed and native code in the same assembly. Basically adding this flag makes the compiler add .NET framework metadata to the assembly.You can also use /clr:safe and /clr:pure flags to generate MSIL-only .NET assemblies in which case C# and C++ are equals here (ditto for VB.NET, J#, etc).
Serguei
+6  A: 

C++/CLI is just the way Microsoft attracts native C++ developers to .NET. It was like a intermediate layer between native C++ and C#, but I'm pretty sure that developers prefer to choose either native C++ or C#.

Microsoft will not let C++/CLI die, at least in near future, however, without community support, C++/CLI will not be able to grow.

In this generation, not growing means close to dead.

Vimvq1987
On the other hand, it looks to me like the programming world has matured a great deal, and I don't expect a whole lot of growth over the next decade. There's no reason why a significant technology can't survive for a long time on a relatively constant user base.
David Thornley
+4  A: 

was it ever alive?

pdeva
+2  A: 

I'm afraid it is.

The reason for this is not C# (which doesn't bring anything special and although it's a new language it doesn't lead in new language features but merely copies features of others - generics).

It's mainly because the first attempt of MS to enable C++ for .NET platform - Managed C++ - was a disaster.
After this they hired Herb Sutter, C++ guru, which made fantastic job designing Managed C++ replacement callled C++/CLI. Why and how much C++/CLI design is superior to Managed C++ design you can find out by reading A Design Rationale for C++/CLI written by Herb.

By the way, Herb made vc compiler one of the best standard-conforming compilers for Windows after years of it being the worst one in regard to standard conformance.

Piotr Dobrogost
I think the Managed Extensions were quite good, better than C++/CLI. Unfortunately it added funny extensions and people didn't like that, so they put different extensions in (sigh) and broke the ability to consume managed resources "natively" (ie on the native heap without putting ^ everywhere). Herb's good, but I don't think he did such a good job with C++/CLI.
gbjbaanb
Have you read "A Design Rationale for C++/CLI"?From what you're saying I guess you haven't...
Piotr Dobrogost
Er, gbjbaanb, if I'm not mistaken, managed resources were never on the native heap. The ^ operator was added to create a distinction between managed objects and unmanaged, because before, managed objects were still on the managed heap, but there was no syntax to indicate such.
Matt Olenik
I never knew that - good job Herb.
DLauer
A: 

I don't think it's necessarily going away, but the reason for using it almost always comes down to whether or not you need the performance benefits that come with it. If C# can do the same thing at 90% of the efficiency of C++, isn't that really good enough?

Jeff Putz
+1  A: 

No. It was born dead. It always has been treated as a second class citezen with no vitality roadmap.

ojblass