Me not really - Linus' critique of C++ had few points that could be rationally debated. A much better researched critique of C++ by Yossi Kreinin is here: http://yosefk.com/c++fqa/
And yeah, I'd much better like to see Kreinin than Linus in a C++ debate.
When reading this rebuttal, keep in mind that it was written in 2010 while the FQA was written starting in 2007, and apparently based on the author's experiences with much older tools. All other things aside, if your compiler frequently miscompiles templates, using them is probably not a good idea.
I agree. Also, C++11 probably makes a good deal of the FQA less relevant (except with regards to the sheer complexity of the language).
Also, I still agree with the basic premise of the FQA: for the majority of new projects where C++ is used, C++ is not the best tool for the job (not taking into account programmer expertise, though even then…).
No. I'd rather like to see Linus talk about Linux (or git) and Bjarne talk about C++. That would be far more interesting than having them fight a flame war over such a silly issue as C vs. C++.
Off topic - but I got to ask - what's up with Microsoft pushing C++ ? They were pushing .NET then all the sudden it's back to C++ (and JavaScript ?). Check out http://channel9.msdn.com/, 5 out of ~9 videos about C++ on the front page. Meanwhile .NET projects like RX seem to be loosing steam, Silverlight is officially dead.
I switched to JVM/Clojure so I haven't been following .NET/MS developments for the last year in detail, when did this push to native happen ? Even better question - why ? .NET finally got to a point where using C++/legacy was justified in niche areas, now they are pushing it to everything (desktop development with C++/WinRT ?)
They could have picked up Mono after Novell, fund it separately (to avoid legal risks) and establish .NET as a truly cross-platform solution.
Or, indeed, Silverlight. But big companies' big technology plays sometimes work, and sometimes don't. Sometimes you get lucky (like the people who never bothered to learn .NET). But I don't think that posting this video represents a major signifier of MS' current technology stance.
I'm not sure that them pushing C++ equates to a switch away from .NET and managed code. What I take from it is that they're keen to foster a rich development eco-system on their platforms and they think that programming language diversity is an important part of this.
As I write this, I realise there is a compelling counter-argument in Apple and Objective-C. So maybe not, I don't know.
Erm, Microsoft are massive. They have lots of customers who have vastly differing needs which generally don't compete with each other.
There are a LOT of Windows applications built on C++. Most games and most intensive applications are C++ based.
Their corporate business customers generally use either C# or VB.Net with a large number still supporting legacy applications in Visual Basic.
Their web customers naturally use javascript/css/html for client-side and one of the managed languages server-side.
So it's not surprising to see them pushing three big languages for their big (and very different) markets.
Microsoft have a pretty good record of supporting their own languages. Visual Basic is still in use today dispite it being terrible. C# is very well supported, and they have a pretty good C++ compiler and toolchain.
IronPython, IronRuby, J# etc were all Microsoft's attempts to "play with the cool kids", clones/forks of existing standards. All died the inevitable death when the next fad came along (see F#).
>Most games and most intensive applications are C++ based.
That's what I'm trying to say. .NET is finally in the place where it's good enough for games (except AAA titles), unlike JVM it supports value types and has true generics that can generate proper collections for them (big deal for games where a lot of the data is in small tuples of floats) and lot's of "unsafe" stuff where you get direct memory access. Mono guys even developed AOT compiler with LLVM optimizer and allowed you to drop things such as runtime bounds checking - you'd probably get to 10% of C++ code, the only remaining problem being non-deterministic GC pauses (can be worked around). Also I don't know why "intensive" applications can't be written on .NET with maybe a few drops to native C when needed. If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable.
But we're arguing different points here. I'm not asking - why is Microsoft supporting C++. What I'm saying is - they seem to be pushing a new fad with this "going native" stuff - and I don't see any rationale behind it. Why actively push for C++ over .NET, .NET doesn't seem to be getting nearly as much attention recently (I could be wrong tough) and let's face it C++ isn't exactly something that needs marketing to get noticed and picked up and it doesn't even seem to be MS strong point in the market.
That's what I'm trying to say. .NET is finally in the place where it's good enough for games
No, it's not. Only for higher level game logic. Even Word made with .NET would fill sluggish. Each layer of convenience has a penalty.
It does gets better with Moore's law, but native also gets better along with it, so the gap remains.
Plus, we always do more stuff with our software, so CPU demands are getting higher too. It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.
That's only true if you can beat the layer implementation, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation.
>It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.
Here you go : http://deltaengine.net/ - used in this game : http://soulcraftgame.com/ a pure managed game engine, cross platform (works on iOS, Android, WP, Windows - XBox/Linux/OSX planned next, possibly ported to other consoles). Also look up indie game titles, XNA, Mono games, etc. It's not AAA stuff, but I never claimed otherwise. Simple tools are far more valuable than performance in many scenarios.
That's only true if you can beat the layer, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation.
We're not talking writing assembly vs having the compiler do it, here. We're talking using a high level language with features such as garbage collection, bounds checking etc, versus not.
Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler".
For an extreme example, a C++ program can easily beat a JRuby program -- despite the JRuby program being run on an optimizing JIT compiler.
The only cost is more programmer work, but not in the scale of difficulty of writing assembly versus C++. And in fields such as Games and Multimedia, you don't sacrifice performance for programmer convenience.
>Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler".
No - those layers were invented because those things were such common errors - ie. - most people got them wrong. So nope, most people aren't able to beat those in everyday code, and debugging is expensive. Performance is not the only metric, even in games, and you have to "beat" the other metrics as well - such as bug count/correctness and productivity. Maybe when you have AAA titles and can budget a few millions on dev team alone the equation looks different, and that's why I singled them out. But for small teams (mobile) and indies/amateurs .NET is good enough (and is being used).
And games regularly sacrifice performance for productivity, look up early unreal script (interpreted), and how it was often the bottle neck but was still used in development.
Especially in the light of Windows 8 and ARM support. Have they announced anything like Apple's Fat binaries? Surely emulating ARM on x86 isn't the whole plan. If it is the marketing of "going native" is a bit amusing. I am just glad the static analysis tools are coming to the low end VS.
If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable.
It is reasonable when you consider that Microsoft has been trying to break Windows into the HPC segment over the past two years or so. The perceived lack of a suitable toolchain and focus on the development of enterprise languages and technologies helped keep Microsoft out of that arena. This re-emphasis on C++ is a necessary, though not sufficient, step if they want to continue pushing for that market.
Off topic - but I got to ask - what's up with Microsoft pushing C++ ? They were pushing .NET then all the sudden it's back to C++
.NET is for corporate stuff mostly. i.e in-company apps, corporate web apps and the like. They never touted .NET as a replacement for C++ for actual Windows apps and they never rewrote their apps (Office, etc) in .NET managed C#. In that area, .NET has been doing well. They don't propose people start using C++ for that, just as .NET was never meant for Desktop application development (and only niche apps use it, like only niche apps use Java for the desktop --Azureus etc).
As for the recent focus on C++, well C++ is having a major new version. And it was always their major weapon for application development (of which there are millions out there for Windows, from major stuff like Photoshop to the lamest shareware crap).
So, .NET/C++: orthogonal.
They could have picked up Mono after Novell, fund it separately (to avoid legal risks) and establish .NET as a truly cross-platform solution.
What sense would that make? So they give their customers a free and open source way to move away from Windows and run their .NET stuff in a Unix stack?
.NET is for corporate stuff mostly. i.e in-company apps, corporate web apps and the like. They never touted .NET as a replacement for C++ for actual Windows apps
I don't agree with that. MFC was used for lots of corporate desktop applications and some if not most of those are being replaced by Windows Forms and WPF apps. Replacing C++ MFC apps with .NET is exactly what Microsoft told Windows developers to do in the past 10 years and that's what they did.
So what part you don't agree with? As I said, "They never touted .NET as a replacement for C++ for actual Windows apps" -- actual as in "not corporate".
So, we're in agreement here.
They did told them to replace old MFC with .NET, but only for corporate desktop applications, not actual shrink-wrapped desktop apps.
You said "So, .NET/C++: orthogonal". I interpreted that as "there is little overlap" and that's what I disagree with. 98% of both in-house or shrink-wrapped desktop apps could easily be written in C#/.NET. Those MFC apps are not just corporate. There's a large number of shrink wrapped desktop apps for all kinds of industries.
We are in total agreement that Microsoft never pushed Adobe to rewrite Photoshop in C#, but Photoshop and MS Office are a tiny, tiny niche as a share of all Windows desktop apps. So when MSDN suddenly starts promoting C++ for Windows desktop apps, I don't believe for a second that their target audience is a handful of Adobe devs.
C++ and .NET are not "orthogonal" at all on the Windows desktop.
You could make a point that their push is entirely about games and graphics/video processing. It didn't sound like that to me though.
>So they give their customers a free and open source way to move away from Windows and run their .NET stuff in a Unix stack?
This is 2012, you don't win by trying to lock in your customers - because people have been burned more than a few times by that business model and there are plenty of alternatives (eg. Java, now with JavaFX 2/3 might make a decent push on the client side, especially if they implement it for iOS/Android).
MS knows that Moore's Law doesn't mean faster cores anymore, rather more of them. But, most problems are only so parallelizable, thus the need to get the utter maximum serial performance (and no less important, minimum power consumption) that you can, out of code. This and, speed advances are going to come in good part from GPU parallelism and, I doubt you're going to get that through the CLR. Herb Sutter, head of the C++ team is all over this -- http://herbsutter.com/welcome-to-the-jungle. C++ and MS' emphasis on parallelism is them facing the future, as they should.
33 comments
[ 3.7 ms ] story [ 86.4 ms ] threadAnd yeah, I'd much better like to see Kreinin than Linus in a C++ debate.
Also, I still agree with the basic premise of the FQA: for the majority of new projects where C++ is used, C++ is not the best tool for the job (not taking into account programmer expertise, though even then…).
I switched to JVM/Clojure so I haven't been following .NET/MS developments for the last year in detail, when did this push to native happen ? Even better question - why ? .NET finally got to a point where using C++/legacy was justified in niche areas, now they are pushing it to everything (desktop development with C++/WinRT ?)
They could have picked up Mono after Novell, fund it separately (to avoid legal risks) and establish .NET as a truly cross-platform solution.
As I write this, I realise there is a compelling counter-argument in Apple and Objective-C. So maybe not, I don't know.
There are a LOT of Windows applications built on C++. Most games and most intensive applications are C++ based.
Their corporate business customers generally use either C# or VB.Net with a large number still supporting legacy applications in Visual Basic.
Their web customers naturally use javascript/css/html for client-side and one of the managed languages server-side.
So it's not surprising to see them pushing three big languages for their big (and very different) markets.
Microsoft have a pretty good record of supporting their own languages. Visual Basic is still in use today dispite it being terrible. C# is very well supported, and they have a pretty good C++ compiler and toolchain.
IronPython, IronRuby, J# etc were all Microsoft's attempts to "play with the cool kids", clones/forks of existing standards. All died the inevitable death when the next fad came along (see F#).
That's what I'm trying to say. .NET is finally in the place where it's good enough for games (except AAA titles), unlike JVM it supports value types and has true generics that can generate proper collections for them (big deal for games where a lot of the data is in small tuples of floats) and lot's of "unsafe" stuff where you get direct memory access. Mono guys even developed AOT compiler with LLVM optimizer and allowed you to drop things such as runtime bounds checking - you'd probably get to 10% of C++ code, the only remaining problem being non-deterministic GC pauses (can be worked around). Also I don't know why "intensive" applications can't be written on .NET with maybe a few drops to native C when needed. If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable.
But we're arguing different points here. I'm not asking - why is Microsoft supporting C++. What I'm saying is - they seem to be pushing a new fad with this "going native" stuff - and I don't see any rationale behind it. Why actively push for C++ over .NET, .NET doesn't seem to be getting nearly as much attention recently (I could be wrong tough) and let's face it C++ isn't exactly something that needs marketing to get noticed and picked up and it doesn't even seem to be MS strong point in the market.
No, it's not. Only for higher level game logic. Even Word made with .NET would fill sluggish. Each layer of convenience has a penalty.
It does gets better with Moore's law, but native also gets better along with it, so the gap remains.
Plus, we always do more stuff with our software, so CPU demands are getting higher too. It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.
That's only true if you can beat the layer implementation, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation.
>It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.
Here you go : http://deltaengine.net/ - used in this game : http://soulcraftgame.com/ a pure managed game engine, cross platform (works on iOS, Android, WP, Windows - XBox/Linux/OSX planned next, possibly ported to other consoles). Also look up indie game titles, XNA, Mono games, etc. It's not AAA stuff, but I never claimed otherwise. Simple tools are far more valuable than performance in many scenarios.
We're not talking writing assembly vs having the compiler do it, here. We're talking using a high level language with features such as garbage collection, bounds checking etc, versus not.
Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler".
For an extreme example, a C++ program can easily beat a JRuby program -- despite the JRuby program being run on an optimizing JIT compiler.
The only cost is more programmer work, but not in the scale of difficulty of writing assembly versus C++. And in fields such as Games and Multimedia, you don't sacrifice performance for programmer convenience.
No - those layers were invented because those things were such common errors - ie. - most people got them wrong. So nope, most people aren't able to beat those in everyday code, and debugging is expensive. Performance is not the only metric, even in games, and you have to "beat" the other metrics as well - such as bug count/correctness and productivity. Maybe when you have AAA titles and can budget a few millions on dev team alone the equation looks different, and that's why I singled them out. But for small teams (mobile) and indies/amateurs .NET is good enough (and is being used).
And games regularly sacrifice performance for productivity, look up early unreal script (interpreted), and how it was often the bottle neck but was still used in development.
It is reasonable when you consider that Microsoft has been trying to break Windows into the HPC segment over the past two years or so. The perceived lack of a suitable toolchain and focus on the development of enterprise languages and technologies helped keep Microsoft out of that arena. This re-emphasis on C++ is a necessary, though not sufficient, step if they want to continue pushing for that market.
.NET is for corporate stuff mostly. i.e in-company apps, corporate web apps and the like. They never touted .NET as a replacement for C++ for actual Windows apps and they never rewrote their apps (Office, etc) in .NET managed C#. In that area, .NET has been doing well. They don't propose people start using C++ for that, just as .NET was never meant for Desktop application development (and only niche apps use it, like only niche apps use Java for the desktop --Azureus etc).
As for the recent focus on C++, well C++ is having a major new version. And it was always their major weapon for application development (of which there are millions out there for Windows, from major stuff like Photoshop to the lamest shareware crap).
So, .NET/C++: orthogonal.
They could have picked up Mono after Novell, fund it separately (to avoid legal risks) and establish .NET as a truly cross-platform solution.
What sense would that make? So they give their customers a free and open source way to move away from Windows and run their .NET stuff in a Unix stack?
I don't agree with that. MFC was used for lots of corporate desktop applications and some if not most of those are being replaced by Windows Forms and WPF apps. Replacing C++ MFC apps with .NET is exactly what Microsoft told Windows developers to do in the past 10 years and that's what they did.
http://www.indeed.com/jobtrends?q=MFC%2C+WPF%2C+winforms&...
So, we're in agreement here.
They did told them to replace old MFC with .NET, but only for corporate desktop applications, not actual shrink-wrapped desktop apps.
We are in total agreement that Microsoft never pushed Adobe to rewrite Photoshop in C#, but Photoshop and MS Office are a tiny, tiny niche as a share of all Windows desktop apps. So when MSDN suddenly starts promoting C++ for Windows desktop apps, I don't believe for a second that their target audience is a handful of Adobe devs.
C++ and .NET are not "orthogonal" at all on the Windows desktop.
You could make a point that their push is entirely about games and graphics/video processing. It didn't sound like that to me though.
Well, I believe they are, except if by Desktop you mean "corporate desktop".
But I mean all the hundreds of millions user desktops, which I don't consider a "tiny niche".
This is 2012, you don't win by trying to lock in your customers - because people have been burned more than a few times by that business model and there are plenty of alternatives (eg. Java, now with JavaFX 2/3 might make a decent push on the client side, especially if they implement it for iOS/Android).
http://stackoverflow.com/a/7524710
1. .NET Framework and Managed C# is the highest programming abstraction level in Windows, and is the way most Windows Apps are now written.
2. The underlining system of .NET is written in C++ and C. And hence is why Microsoft is supporting unmanaged C++. Because it's part of everything.
3. WPF/xaml hasn't died. It has replaced WinForms. And is #1 way UIs are now written.
*This will all be complemented with the new Metro interface where JS/HTML5 are now also part of the top level.