As a C++ stickler, this has really been bugging me. I've always liked the idea of the "language-independant framework" that Microsoft came up with roughly a decade ago. Why have they dropped the ball on this idea? Does anyone know the reasoning behind it?
+1
A:
It bugs me too, if they had supported it, we'd be able to migrate our C++ code to a new GUI much easier and cheaper than basically rewriting everything in C#. Its costing us a fortune to rework our apps, just what we wanted in a recession.
I imagine the reasoning is that C# is popular (and not as cross platform as C++) so they've decided to keep their development efforts to the minimum required.
gbjbaanb
2009-08-06 22:29:47
+2
A:
If it were me my reasoning would be that C++.Net should not be used to write GUIs.
I'm not trying to be snarky here, maybe someone can show me the error of my ways but I don't think it's a good idea. I'm messing around with one right now and development much much slower than if the application had been written in C#. My feeling is if features in C++.Net or just regular C++ are required for the application it seems like a better idea would be to create a DLL to do the heavy lifting and could interface with C#.
Spencer Ruport
2009-08-06 22:30:14
that's simply because C# has all the effort put into it to make it easy. They could do that with C++, if they wanted to. They just don't.
gbjbaanb
2009-08-06 22:39:58
Is there a good reason to?
Spencer Ruport
2009-08-06 22:43:52
Is there a good reason to have a multiple-language runtime at all, if it turns out to be too much work to support GUI programming in all the languages?
Steve Jessop
2009-08-06 22:53:52
@onebyone: Only if they have applicable differences. IE: Linq vs. F# vs. C#. Otherwise, not really. I never hear about J# anymore and VB.Net seems like it's days are numbered. If you're asking if C++ should interface with .Net at all yes. It's a real pain when two languages aren't aware of ANY of the others data types. IE: The ability for C++ to use a .Net Generic Dictionary directly is a huge time saver when you're trying to interface it's heavy lifting abilities with C#'s ease of use which is what I mentioned above. But beyond data types I think it's pretty pointless.
Spencer Ruport
2009-08-06 23:05:42
Fair enough. So effectively, Microsoft is removing the illusion of choice, and the different CLR languages should be clearly demarcated for particular purposes? C# for general programming, C++ for fiddly optimisation, F# for showing off your leet functional credentials ;-)
Steve Jessop
2009-08-06 23:13:52
@onebyone: It wasn't always an illusion. Initially I believe J#, VB.Net, C# and C++ were all supported equally. What would you prefer they do? Continue supporting dead or less popular syntaxes (J#, VB.Net) and supporting features that encourage the improper use of languages? Or should they continue developing useful stuff like LINQ, F# and improving upon C# syntax? (I'm still psyched about string MyProperty {get; set;} personally.)
Spencer Ruport
2009-08-06 23:26:00
Well, MS gets to define "improper". If it wants to support C++ as a GUI programming language it can, and if it's happier encouraging app developers to take up C#, it can do that instead. Or a third party could maybe do work to offer fuller support for C++, if there's demand. Personally I don't mind: I don't know C#, but then I don't program .NET either. I'm just curious where the wind is blowing. In principle I'm more interested in IronPython than I ever will be in J# - Java's OK, but C# has already incorporated all the bits MS thought were worthwhile, so it was only ever a stopgap.
Steve Jessop
2009-08-06 23:32:45
if they're going to demarcate languages for different purposes, they should go the whole hog - one for GUIs, one for data manipulation, one for data access.. think how streamlined each language could be.
gbjbaanb
2009-08-07 09:08:03
Well, that sort of is what they've been doing with LINQ and XAML. I doubt whether this allows C# to be streamlined much, other than ditching some library bindings, since it's supposed to be the language in the middle. But C++ is massive overkill if its future role is just as the break-out language for heavy lifting. I like C++, but you don't want an 800 page language standard to hit your desk just to optimize your video codec. Question is how to get from here to wherever MS wants to be.
Steve Jessop
2009-08-07 10:36:48
+2
A:
Part of the reason will be that C++ support is actually two languages in one -- the native and the CLI variants; that extra development load has been acknowledged by the Visual C++ team as the reason that proper MSBuild integration lagged (lags? I haven't checked in 2008 or later) behind other languages.
Another part will be to do with the code generation during compilation that goes on in a C# build to support e.g. the binding "magic"; I've found that even in F#, you don't get it "just happening".
Steve Gilham
2009-08-06 22:31:47
A:
You can do WPF with managed C++.
The reason is nearly all new application programming is now Script , Java , VB.NET or C# . All GC languages . The emphasis is on higher quality for a lower skill set and C++ demands too much from the developer , companies want people to write log bug code on their first day.
C++ for applications is mainly for maintenance of existing applications or where extreme performance is needed. Device drivers and OS are still frequently written in C++ but even that is changing ( Coyotos is Cbit , E# , Cosmos/Mosa are C# , Singularity/Midori).
Regards,
Benk
2009-10-15 04:19:54