John Sonmez wrote a nice article on the weekend – both the article and the comments are worth reading.
“Why C++ Is Not ‘Back’”
by John Sonmez
I love C++. […] There are plenty of excellent developers I know today that still use C++ and teach others how to use it and there is nothing at all wrong with that.
So what is the problem then?
[…] Everyone keeps asking me if they need to learn C++, but just like my answer was a few years ago, it is the same today—NO!
Ok, so “NO” in caps is a bit harsh. A better answer is “why?”
[…]
Although I don’t agree with everything John says, he presents something quite valuable, and unfortunately rare: a thoughtful hype-free opinion. This is valuable especially when (not just “even when”) it differs from your own opinion, because combining different thoughtful views of the same thing gives something exceedingly important and precious: perspective.
By definition, depth perception is something you get from seeing and combining more than one point of view. This is why one of my favorite parts of any conference or group interview is discussions between experts on points where they disagree – because experts do regularly disagree, and when they each present their thoughtful reasons and qualifications and specific cases (not just hype), you get to see why a point is valid, when it is valid and not valid, how it applies to a specific situation or doesn’t, and so on.
I encourage you to read the article and the comments. This quote isn’t the only thing I don’t fully agree with, but it’s the one thing I’ll respond to a little from the article:
There are only about three sensible reasons to learn C++ today that I can think of.
There are other major reasons in addition to those, such as:
- Servicing, which is harder when you depend on a runtime.
- Testing, since you lose the ability to test your entire application (compare doing all-static or mostly-static linking with having your application often be compiled/jitted for the first time on an end user’s machine).
These aren’t bad things in themselves, just tradeoffs and reasons to prefer native code vs managed code depending on your application’s needs.
But even the three points John does mention are very broad reasons that apply often, especially the issue of control over memory layouts, to the point where I would say: In any language, if you are serious about performance you will be using arrays a lot (not “always,” just “a lot”). Some languages make that easier and give you much better control over layout in general and arrays in particular, while other languages/environments make it harder (possible! but harder) and you have to “opt out” or “work against” the language’s/runtime’s strong preference for pointer-chasing node-based data structures.
For more, please see also my April 2012 Lang.NEXT talk “(Not Your Father’s) C++”, especially the second half:
- From 19:20, I try to contrast the value and tenets of C++ and of managed language/environments, including that each is making a legitimate and useful design choice.
- From 36:00, I try to address the question of: “can managed languages do essentially everything that’s interesting, so native C/C++ code should be really just for things like device drivers?”
- From 39:00, I talk about when each one is valuable and should be used, especially that if programmer time is your biggest cost, that’s what you should optimize for and it’s exactly what managed languages/environments are designed for.
But again, I encourage you to read John’s article – and the comments – yourself. There’s an unusually high signal-to-noise ratio here.
It’s always nice to encounter a thoughtful balanced piece of writing, whether or not we agree with every detail. Thanks, John!
Sutter’s Mill 
I have a love-hate relationship with c++. I like the plain abstraction, its syntax and its value semantics. On the other hand I cannot appreciate the following things:
– compilation speed. In my work we have a 100 project solution, which takes 1 hour to build. We already use pch and all the compilation tricks. Other people here use c# and that compiles in minutes. Is it related to all the Boost template stuff, or is MS deliberately holding back c++ compilation?
– templates. They are very handy but there are many dark corners. When we upgraded to vstudio 2008 we encountered a problem which took us days. It turned out to be a non obvious issue which was correctly rejected.
– c++ tendency to allow redefinition of variables in various scopes. Also with overloads there are many pitfalls.
– universal references. I am not sure who voted the current syntax in. The rules of turning a rvalue into a lvalue are not obvious.
– backward compatibility is good for the short term (everything stays compilable) but blocks long term evolution. I wouldn’t mind if a proposal break old code if that would improve build speeds (e.g. in the template syntax). Ofc there is many c++ code written, but can’t this be solved by compiler flags? K&R C has also died.
Managed languages are the right choice for the large majority of use cases. C is usually the most pragmatic choice for use cases that call for a lower level of abstraction and/or higher level of control.
C++ just doesn’t have enough to offer to justify it’s horrifying complexity, internal inconsistency and glacial compilation speed. Ensuring the job security of and dependence upon the sadists willing to learn it is just about the only thing it has going for it.
@Bob
” 9 out of every 10 job postings do not require knowledge of c++ or c”
9 out of every 10 programmer in the world knows gc’d language like c#/java/python etc. More demand, more supply.
There is currently a higher demand for programmers than can be filled. I am guessing 9 out of every 10 job postings do not require knowledge of c++ or c and only expect training in a gc’d language like c#/java/python etc. So given this metric I’d agree with John that you don’t “need” it unless you really
want to pursue a field that demands it’s
low evel/latency. Secondly with Moores law approaching an end a low energy intensity language like c++ only becomes more valuable as embedded devices become more and more ubiquitous in our daily lives. I hope the c++ standards committee considers this and supports additions that are ‘light’ and most importantly safe as lives will depend on code correctness.
It is waste of time fighting over languages because one language does not suit all industries. I worked mainly in the financial industry where C++ is used extensively. I have seen good C++ developers quitting jobs for better opportunities/pay and non-C++ developers getting fired. It many be different in other industries.
For me the biggest problem with C++ is code readability, and maintainability. When you read C++ code (especially written by someone else) you can never be sure what it means, and what path it will follow. The many examples on GotW just reinforces this feeling, that I have to do a small research when I read a single line of code because it could mean 7 things.
Thank you for your reply, Herb!
@Joe: Please keep in mind that Dalvik VM is not the best implementation of Java. In fact XobotOS (Android ported to C#) is much faster than Dalvik (http://www.infoq.com/news/2012/05/XobotOS).
@earwicker: I do agree that brittleness in general is bad, and one of the limitations of C++ that I will readily admit is that it is unforgiving of sloppiness. Unfortunately, with C++ it can lead to the introduction of subtle bugs if there isn’t pretty strong code review catching such things.
That said, I also believe that sloppy programmers cost you time and money no matter what language you are using. They tend to create unmaintainable software that requires refactoring. I don’t really believe that C++ is any less conducive to refactoring than C#, however, aside from that the tools for doing so are well behind what’s available in C#.
As for the getting X right from the beginning stuff, that is advice meant to tell you that if you don’t include such considerations from the start then you can be ready for completely overhauling your architecture – to the point of basically starting from scratch – when you finally realize that what you have is fundamentally unable to support what you need to do. There is no language that makes such things easy, and I haven’t really found the care you have to exercise in C++ in avoiding undefined behavior to be the real limiting factor there.
I’m not going to defend how easy it is to trash memory in C or C++, but on the other hand it’s a problem I rarely encounter simply because I don’t do much pointer arithmetic, and I don’t allow developers working on my projects to do so, either.
Also, while the sky may not have fallen with Android requiring applications to be written in Java, and despite the fact that I prefer Android to iOS, I can also admit that I have seen even high-end Android phones get laggy in a way I haven’t really experienced on iOS. It’s not sky-falling bad, but it is noticeable, and it’s something I wish wouldn’t happen. Now, whether that’s the fact that everything is running in the Dalvik VM I can’t say, but it is a real phenomenon.
@Joe – “I also don’t find the “resources don’t matter” argument particularly convincing.”
You’re absolutely right there – we have yet to reach the far-off horizon where computation is free. In particular, when your software is running in the cloud you are typically charged in real money for every CPU cycle you waste! So it is possible to put a dollar value on the ability to save cycles and for a very heavily used application it will quickly add up to something worthwhile.
Same goes for mobile devices and battery life, of course.
But what of the assumption that C++ (or any other language that inherits C’s memory-trashing undefined behaviour foundations, such as Objective C) is the solution to this problem?
Almost all Android apps are written in Java and run in a virtual machine, and the sky hasn’t fallen in yet. Why is that? C++ offers the power of micro-optimisation, but we all know that the big savings come from choosing the right algorithms.
The most widely abused phrase in software advice is “You have to get X right from the beginning, it can’t be bolted on as an afterthought”. The problem here is that X can be practically anything about your software (security, thread-safety, usability, performant algorithms), and we can’t do it all from the beginning and get it right, because they are all choices that affect each other! Something’s got to give. What we need is the ability to change our minds as we go along. i.e. we need software that is malleable, not brittle: easy to modify while preserving correctness, etc.
This, ultimately, is why C’s memory-trashing undefined behaviour foundations are a problem: because they contribute to brittleness. A working C/C++/Objective C program is balanced on a tightrope halfway across the Grand Canyon, and the best thing to do is try not to shake the tightrope. Acrobatics are out of the question at that point.
I find it interesting that someone mentions WPF as a highly productive tool for GUIs when I have found it to be the opposite. It’s quite quick when you want to do flashy things, but if you need standard Windows behavior, you frequently have to reimplement it yourself, because the framework doesn’t provide it out of the box (for example, something as simple as graying out a button with an icon when it’s disabled requires writing your own image filter – but it just happens in the C API).
The result is an army of developers reinventing the square wheel as they poorly approximate the behavior of every normal application. Windows Forms is better about this, since it’s a thin wrapper around the Windows API, but it’s far from perfect. The number of C# developers who understand even the basics of window relationships and whether a window should or should not appear on the taskbar, how to put a window on top of its owner without putting it on top of every window in the system, etc., is shockingly small. But then if speed is your main goal and not correctness or making good use of system resources, C# is a great choice. Right tool for the job and all that.
Don’t get me wrong. I actually like C# quite a bit. But I think the benefits are oversold (though not to the absurd hype degree they were with Java).
As for the portability argument, having actually written portable code in both C# and C++ that ran on both Windows and Android, I can say I vastly prefer C++ for the task. Mono is nice, but it isn’t a panacea. New versions of the framework have required me to change my code to keep it compiling. Once I ported my support libraries – which took time, but not a lot in the grand scheme of things – I never touch my C++ code. And the C++ code is noticeably faster to start up.
I would also throw in for the benefits of RAII over anything that the managed languages offer. C++ / CLI is the only exception, because it has the right idea with allowing you to treat managed objects as though they were scope-bound. Really, the managed languages could have this if they allowed you to attach an implicit finally to every instance of an object, but they don’t. The using and try-with-resources statements are very poor approximations of RAII, and the amount of code in C# I have seen where developers fail to release resources properly makes any arguments that these languages let you concentrate on more important things than that ring hollow. Garbage collection is nice, but I haven’t found myself spending all that much time worrying about memory management in C++, either.
I also don’t find the “resources don’t matter” argument particularly convincing. While it’s not uncommon anymore for even cheap machines to have 4 to 8 GB of RAM, if the user has to run a number of these resource-hungry programs, or if they are using other programs that legitimately use a lot of RAM, it’s not as much RAM as it sounds like. Also, my experience with WPF-based programs in particular is that they are shamefully slow to start up – for example, I can click the icon for Visual Studio 2010, let the splash screen display for 10-15 seconds, then click the icon for Visual Studio 2008 and 2008 will still finish loading well before 2010.
That said, I do appreciate when someone can talk about the limitations of C++, which are unarguably there, without resorting to the Linus Torvalds or C++ FQA methods.
@Jason Bilmez
You’re far too hard on John, calling him “full of hot air”. It’s as if you don’t think people are entitled to opinions unless they are drenched in facts and figures to support them. John was quite reasonable in this thoughts on C++ and I don’t think you gave him fair credit for that.
The fact is, if John presented facts and figures, you’d just argue about those and so would I and everyone else, but It wouldn’t change a thing.
You’re missing the point: John relayed his life experience with C++ and C#, not some theoretical opinion or language analysis of them. No amount of facts can undo or re-live his experience as it is what he experienced and what he was relaying. It doesn’t neccessarily make him wrong or full of hot air just because his experience doesn’t match yours.
In other words, just because John “can’t handle” C++ and maybe you (Jason) can; that doesn’t mean C++ is not high maintenance. Give John a break.
It’s like trying to advise the guy reading all this who’s thinking “C# or C++? – which is right for me?”. The answer is “whichever one you can handle best!”. That probably isn’t the answer they want to hear, but it’s probably the only honest answer anyone can simply offer in this case.
What else do you say: “Do you like an easy life?”, “Do you like catching tigers by the tail?”.
People are different, hence all the debate and differences. Some catch tigers better than others. Some get bitten. Who are the smarter ones, those avoiding the risks of getting bitten or those catching tigers tails?
For myself, I too find C++ less productive than C#, but I choose to blame it on the tools more than the language.
John has taken his a side. I personally find C++ more enjoyable than C# and have the opinion that if the tooling for C++ catches up to C# (and it almost has), I’ll be as productive in C++ as C# if not more so and hopefully that’ll mean people will let me keep using C++. But will they?
Not everyone will catch tigers by the tail even with better tools and maybe the world will go with with them. So the jury is far from in on that and so asking is C++ back, will it stay, did it ever leave, will C++ “beat” C#, these are all fair questions to wonder. I don’t know, “I hope so” is my answer.
I hope Herb gets C++ VS2013 out the door with all the features we could ever need, if he does that, maybe John will come back to C++ and prove himself wrong, who knows. It’s open to go either way IMO.
What I can say is that John definitely is not “full of hot air” for wondering these quesitons out loud. That much I do know. I think that was Herb’s basic point too. We can be C++ fans, but we should not be zealots.
@earwicker
You are right, why would we use a language that supports something we don’t want to do? Going back to your knife analogy, why use a knife when we could use a slicer specific to what we are trying to cut? I mean, with a knife you can cut all kinds of things, including things you will never want to cut! Plus, you might cut your finger, or accidentally stab someone else! Using a slicer with hand guards that is specific to the object being cut is much safer, and more efficient.
@Rob G – “I’ve been programming in C++ for around 20 years, and have never found that I have to treat memory as a flat space.”
Yes, me too. But about five years ago, I realised: why use a language that supports something you’d never want to do? Which allows you so easily to do it by accident?
“In modern C++, you can use standard collection classes and – and this is an area I’ve yet to see in most mainstream languages – algorithms. This allows programming at a very high level of abstraction with effectively no cost.”
Are you entirely happy with back_inserter and the way it has to be used when writing to the end of a vector (and what happens if you don’t)? If so, I have to ask you the same question you asked me: are you serious? :)
It should also be well known that C++ is not unique in having a library of reusable algorithms that work over sequences.
@Michael said “The only reason that makes C++ syntax ugly, and tools difficult to write for, is that C++ syntax is not LR(1).”,
Fortunately, the CLang project exposes the parser. Hopefully, this will lead to a number of tools that help in this direction. I’m hoping other compilers will follow suit.
@earwicker – Are you serious? I’ve been programming in C++ for around 20 years, and have never found that I have to treat memory as a flat space. Indeed, the language, more than any other I’ve used, allows the developer to design to take the constraints of memory architectures into consideration.
In modern C++, you can use standard collection classes and – and this is an area I’ve yet to see in most mainstream languages – algorithms. This allows programming at a very high level of abstraction with effectively no cost.
There are many great similarities between C++ and the other languages being discussed here. With C++11 (and even Java 8) the gap shrinks further. But there is one fundamental difference that will never be usefully eliminated and that is the way that C++ assumes that memory is a uniform array of randomly accessible bunches of bits of fixed size. (Of course the C++ standard is written in such a way as to disguise this assumption but there is no practical way to implement C++ without assuming a flat address space of raw numbers that can be reinterpreted by the code however it wishes).
But it has to be recognised that the flat address space is itself an *abstraction*. It is not the lowest-level representation. The OS has to go to some effort to trick each user process into believing that it has access to a flat address space. Access is definitely NOT uniformly fast across all memory: any C++ expert on performance will tell you about the importance of understanding all the layers of caching: the CPU levels, main memory, virtual memory, and that each of these can be hundreds or thousands of times faster than the next.
What is the purpose of this abstraction? It obscures the performance characteristics, hiding them behind an illusion – I’d go further and call it a lie! That’s how misleading it is, from a performance perspective. To write fast code in C++ you have to know that memory isn’t really a flat space.
So perhaps the purpose of the flat memory abstraction is ease-of-use: “Okay, your program may be slow, but it will easy to get right!” But no one could seriously defend it on that basis when comparing it with the most popular alternative: the managed memory abstraction, in which we allocate objects such that it is simply not possible to read (or write) “before” or “after” the object – such locations don’t exist, there being no operations provided for accessing them, the notion of a type is fundamental so a given memory unit always stores an object of a known concrete type (seems kind of sensible, doesn’t it?) and as an added bonus we tend to get practically perfect (non-conservative, compacting, very fast to allocate) GC under this abstraction.
Of course, as Mr Sutter has demonstrated, it is possible to create a new language (lets call it C++/CLI /clr:safe!) in which we provide new features that assume the managed memory abstraction, and simultaneously eliminate all the features of the language that assume the flat address space abstraction. But there are various obstacles to the user community of that language ever becoming as large as those of C++, Java or C#. It requires you to completely rewrite your existing C++ code, and given that hurdle, most people will look at easier-to-learn languages instead.
I think the fundamental principle that people do not understand is we have to be productive. Language is just a means to talk to the computer, and all languages are built on some usage specs. Every body have to choose the language based on the specs they have at hand, time line for development, and their current skills. Rather than trying hard to adapt a particular language to job at hand, we have to delve into our skill sets and think what can make the things easier.
We can always use a Sword to cut vegetables, but why use knife? Just so that we do the work easily, be safe, save our head, and hand, and also spend time with our friends and family. So I do not think C++ was gone or will go away or rule the world. These debates are getting converted to religious discussions.
* Although I love C++ I do not wish to write web pages in C++. Why? Simple I do not want brain surgery.
* Although I love C++ I talk to my “Human” friends in plain English or my native language. I do not wish “Happy birth day” like “std::cout<<Happy Birthday<<std::endl" to my friend. rather I use plain English. Why? Because English is the right tool to use there (Human to Human talk).
* Although I love C++ I am writing these comments in English rather than C++, though I know most of the people here are far more knowledgeable in C++ than I am.
* Although I love C++ I have I use gmail or yahoo mail, rather than get my hands dirty with a e-mail api, create a mail server, compose my email, build it and execute it to send it. Because I know of better tools to send mail. I don't give damn about the language they use to send my mail.
So in simple terms, be productive, and most importantly happy. Always use the right tool. Do not shape your foot as per your shoes, always buy the right shoes.
And regarding C++, I do not think it is complicated. Learning is a gradual process, regardless of any language you use, you have to learn. The main thing is keep on learning, and improve your skills and the programs you write. Just tell me any one here who always write code that is never modified or improved?
C++ provides you different tools, you have to use the best one/ones. Its not like you can't compile a program if you do not write templates or don't use r-value or blah blah features. You can compile a simple loop, which has the same structure in all languages.
Languages are like rivers, always small stream of libraries or features will be added to them. It happens with all languages, natural language too. The new features in C++ are not bogus, it adds expressiveness to them. Lets you type less, care about memory less.
So start from specs, reflect on your skill sets, and see what can be best for you. If you choose C++ do not be afraid. But remember, C++ can't heal a wound, medicine and doctors are the right tools.
> You will find this to be true, for example, with the new uniform initialization syntax. Once enough people have migrated to the new syntax, which is better in virtually every way, sometime in the future we could contemplate removing the old and shearing off complexity. In the meantime, the old complexity and several Effective C++ Items can be ignored (such as a infamous vexing parse), as you simply won’t encounter those issues if you use only the new initialization syntax.
If the new way is better in virtually every way but we need to keep backwards-compatibility anyway, a recommendation to compiler writers to spit out a warning when the old way is used, would be very welcome – unless something is *actively nudging* users into doing things *only* the new way, the “language is bigger” issue would still exist because newcomers need to learn the old way, the new way, *and* why the new way is better.
The only reason that makes C++ syntax ugly, and tools difficult to write for, is that C++ syntax is not LR(1). Take a look at the managed languages and notice that their tool support is vastly superior to C++. Cut the backwards compatibility and make the language easy to parse. Too bad this will never happen.
Another reason is, there’s no one standard ubiquitous library that provides a way for people to work in an “I just want this done and will care about performance later” manner. Not everyone wants to waste time selecting a library when a standard one is available. Contrast Java’s standard library, Microsoft’s BCL with the standard C++11 library…libraries are what make people productive, I’d say waaaay more frequently than a new language feature does unless the old language was so deficient, which I never felt C++ was (well, the new use of the auto keyword is good, but it’s icing on the cake)
Well, maybe Boost is, but it’s still not standard. The day the entire Boost library is incorporated as part of standard C++ will be the day of its resurgence. Regex, and Threading are in the right direction but not enough. Most applications can use a few more features in , built-in HTTP support, UTF-8 without adding ICS, etc.
“C++ *does not allow them to do that* – there’s just too much that can go wrong; until you’re a C++ expert you will be writing code that is fundamentally unsound. That’s not something to be proud of. That’s a failure!”
This is absolutely NOT true. If an non-expert isn’t writing fundamentally sound code in C++, he won’t be writing it in any other language either. You don’t have to know the language inside and out to write robust code that does the job. In my 20 years of programming mostly in C++, 90% of the code I’ve written has used probably only the core 30% to 40% of the language.
You can spell spaghetti in any language. I’ve seen a lot of C++ code written by idiots, and lot of C#, Basic, Java, and Delphi code written by idiots. It’s every bit of it crap, and it’s not the fault of the languages. It’s the fault of the idiots who code without understanding. The same people who code without understanding in C++, code without understanding in C# or Basic or Java or whatever language you care to name.
On the notion that C#, etc. is somehow faster to write in… I have not found this to be the case. In fact, the lack of RAII in the language, and the crap that’s been added to get around that, for me, make it slower to write good code. And why does everyone hate on multiple inheritance all the time? If you don’t need it, don’t use it. It will cost you nothing if you don’t use it. You should prefer composition to inheritance anyway, regardless of the language you’re writing in. And guess what? The managed languages have a weak form of multiple inheritance kludged in anyway. It’s called interfaces. Going back to my earlier point, the programmers who would misuse multiple inheritance are going to misuse the features of whatever language they’re programming in.
The problem is not the language, the problem is the programmers. I’ve had far too many coworkers who have no clue that blogs like this exist, or that these sorts of discussion occur. They know what they learned in school. They know what they might learn in any training their employers put them through. But that’s all they know. They have no curiosity or desire to improve their craft. They don’t unit test, let alone write code that’s unit testable.
Some really strange comments here. The idea that C++ is extremely difficult is garbage. You can make it that way but it is very possible to write clear and well organized programs in C++ without getting bogged down in esoterica. If you focus on using the more advanced concepts then of course you will have a longer learning curve.
Mind you I’m far from being a professional programmer yet have code that was written by me running production for years. Sadly one reason I’ve switched to Python, for some things, has little to do with code complexity of C++ but rather the excellent libraries that are more or less standard and available for Python. The standard library and boost simply aren’t enough in comparison.
So if I might suggest to those in the standards making process, we don’t need continuous revisions to C++ that deny the importance of standard libraries. In fact beyond modules I can’t think of anything more important for C++15 than a significantly improved standard library. The idea that a language can exist alone without a well thought out and standardized library is just asinine these days. At the end of the day it isn’t that Python is “”simpler”” as it isn’t really, it is the library support that makes a difference.
One other thing which may be hard to do with C++ right now, but C++ could be vastly improved readability wise by moving away from ASCII limited character sets. Maybe that would require a new language, “E” maybe, but having an expanded character set, if used wisely could lead to far more readable C++ code. I still find it funny that at this point in time languages still insist on 8(7) bit character sets. In the end reading C++ often isn’t difficult from the comprehension stand point but rather is difficult from the mental parsing that has to go on.
As an engineer, and not a computer scientist, I think a lot of the language warriors are missing an important point. The days of “One Language To Rule Them All” are over, dead and gone. I think we’re entering an era of using the right tool and the right skillset for the job. The Engineering disciplines have been doing that for a long time, whereas in programming that approach is still pretty immature (but growing fast). The right tool for the job is why other languages and platforms are growing alongside C++. C++ isn’t dropping off much though.
High-performance parallel math code is still mostly written in Fortran, because it’s the best tool for the job. Some is in C. A high-performance cache-aware BLAS library in C#? Yeah, right. It’s the wrong tool. So is C++ for that matter. C++ is the tool for fine-grained application parallelism though (Intel TBB & friends), and multi/manycore is everywhere. Need a GUI and higher-level business logic? C#/WPF, Java, and/or JS/HTML5. On average, you’ll deliver that faster with those technologies than you will with C++. Yeah , I know there’s QT for C++ GUIs, I like it a lot, but even as a C++ expert I’m still faster and more efficient with C#/WPF doing GUI development.
Along with One Language To Rule Them All going the way of the dinosaurs, so is only having one major skillset (if all you have is a hammer, everything looks like a nail….) If you’re only good at one thing, your career is going to be pretty limited anyway.
C++ is only complicated because certain old “features” still have to be used, once new modern variants of these things are in, the language will be a great deal more enjoyable
header files + slow compilation -> modules
monomorphic lambda -> polymorphic lambda with hopefully less syntax
complex pure functional language used for compile time manipulation -> better compile time evaluation(static_if, better CTFE)
no reflection, forcing idiotic custom “solutions” -> compile time reflection
But anyway, C# is no solution, its abstraction and reuse capabilities are worse then C++ as it stands today! Generic are a joke compared to templates. D gets many things right, which C++ (currently) gets wrong, although it missed the target on a few key things(GC, classes).
General: Thanks for the generally high level of comments, especially nearer the start. I was hoping this would continue as a balanced discussion instead of degenerating into barbs. :)
A few thoughts:
Paraphrasing Bjarne, I usually summarize C++’s three top (but not only) strengths as: (a) efficient abstraction (abstractions often compile away, don’t pay for what you don’t use, leave no room for a language lower, etc.); (b) flexibility (you can always express what you want, opt out of guard rails, etc.); and (c) portability (you get the efficiently on all platforms, programs you can largely take anywhere as long as you put any platform-specific code in a particular module and just port that and the rest comes along).
In that context:
@Zenju: Yes, C++ always lets you “open the hood” and take control. I would always add, though, that you don’t always need to open the hood. It’s just that you can whenever you need to.
@Magnum: Actually, I do hear a lot from people who find themselves enormously more productive when they switch to C#. And that’s fine — I know others feel the other way, but it depends very much on what you’re doing. As Andrei Alexandrescu put it in a talk last year, ‘developing code in C++ is generally slower than in other languages, but paradoxically developing efficient code is faster in C++.’ The reason is that that’s what it’s geared for — efficiently by default, efficiency as a first-order concern, with the ability to opt out. If you’re not targeting the three (a)/(b)/(c) C++ design values above, you’ll have a worse experience in C++, not because C++ sucks or because you suck :) but just because of “fit” — not using an appropriate tool, one designed for the job you want to do. If you are targeting those design values, then you’ll have a worse experience in Java and C#, not because they suck or because you suck :) but just because you should be using a different tool. So much of these debates come down to using the right tool for the job..
@Jon: Yes, C++ is complex and the complexity is largely because of C compatibility. I agree with Bjarne that there’s a small language struggling to get out — I’ve participated in private experiments to specify such a language, and you can do it in well under half the complexity of C++ without losing the expressivity and flexibility of C++. However, it does require changes to syntax (mainly) and semantics (secondarily) that amount to making it a new language, which makes it a massive breaking change for programs (where existing code doesn’t compile and would need to be rewritten manually or with a tool) and programmers (where existing developers need retraining). That’s a very big tradeoff. So just as C++ ‘won’ in the 90s because of its own strengths plus its C compatibility, C++11 is being adopted because of its own strengths plus its C++98 compatibility. At the end of the day compatibility continues to be a very strong force and advantage that isn’t lightly tossed aside to “improve” things. However, it’s still worthwhile and some interesting things may come of it. Stay tuned, but expect (possible) news in years rather than months.
@tonyk; Actually, no, a good C++ programmer doesn’t need to know all those things. That’s a common misconception though. And “ADDING” features can make a language simpler, because it migrates people to using the new simpler alternatives instead of the old ones. You will find this to be true, for example, with the new uniform initialization syntax. Once enough people have migrated to the new syntax, which is better in virtually every way, sometime in the future we could contemplate removing the old and shearing off complexity. In the meantime, the old complexity and several Effective C++ Items can be ignored (such as a infamous vexing parse), as you simply won’t encounter those issues if you use only the new initialization syntax.
General philosophical question: “When does adding a feature make a language simpler?” When it lets you express your intent more directly, notably by adding direct support for an important abstraction (e.g., virtual functions), or to express your intent more consistently, such as by adding a simpler facility that lets you ignore multiple older complex options.
@bittermanandy @LoupValiant: I agree that what Don Box calls “reveling in complexity” is generally a bad thing regardless of language. C++ has complexity, and some do revel in it. But “just because you can doesn’t mean you should” — that’s a knock against them (IMO) rather than against C++.
From Joe Duffy’s Weblog; http://www.bluebytesoftware.com/blog/2012/10/31/BewareTheString.aspx
.NET holds an enormous advantage over C++.
That might sound like an oxymoron, but our system can in fact beat the pants off all the popular native programming environments. The key to success? Thought and discipline.
“If (as it may be reasonable to argue) you need to be a C++ expert to use it “properly”, that is a point against it! Stop bragging about how good you personally are at C++ and how anyone who’d rather use a different language is just too uneducated to understand it.”
Good luck with that one. People mostly don’t want to solve problems, they want to show how smart they are (that would include me to some extent). That’s how some people do Template Meta-programming with a straight face, instead of fixing the compiler, or writing a real macro system —that’s how C++ itself started out for Church’s sake!— or just choose a simpler language.
Think of this a big status game for a minute. Simple solutions are hard to reward because they don’t do justice to the difficulty of the original problem. Complicated solutions on the other hand are much better at making the programmer look smart. Add some “industrial strength” in the sales speech, and you get one of the reasons for C++ success.
I don’t know how to solve this. Ideally, we would have miracle tools that both yield simple solutions *and* make their users look smart. I’m afraid the two are at odds.
Nothing frustrates me more (and it’s been seen among these very comments right here!) than the attitude that “if you don’t think C++ is best, you just don’t know it well enough”. The commenter is sometimes, but not always, honest enough to add the epithet “…n00b”.
I actually know C++ pretty damn well. Not as well as, say… Herb Sutter… but I’ve read a lot of his books, and others, and have a decade or so of hands-on professional C++ experience. I know the language, I know its uses, I’m not a guru but I am an expert. And the problem domains in which it is appropriate to use C++ are dwindling fast.
If (as it may be reasonable to argue) you need to be a C++ expert to use it “properly”, that is a point against it! Stop bragging about how good you personally are at C++ and how anyone who’d rather use a different language is just too uneducated to understand it. Consider instead whether the vanishingly small number of C++ gurus in the world can write enough code on their own to keep the whole world going. Of course they can’t.
An educated, intelligent programmer who has not achieved expert or guru status should be able to use a language that allows them to be productive and, notwithstanding the fact that all code has some bugs, write software that basically works… and write that code quickly and efficiently. C++ *does not allow them to do that* – there’s just too much that can go wrong; until you’re a C++ expert you will be writing code that is fundamentally unsound. That’s not something to be proud of. That’s a failure!
There are, *absolutely*, cases where C++ is still a valid choice or even the optimal choice. (I would be worried about my own future employment prospects if this were not the case). There are far more cases – the 90% case – where you just need to quickly write code that works. CPU efficiency? It’d be nice, but Herb’s promised us 256 processors next year. Memory efficiency? It’d be nice, but my phone has more RAM than my Windows PC ever actually seems to use. Let’s get the software done fast and use it. C++ is not a language that supports that priority… not even in C++11.
The 10% case (where performance and optimisation matters) still exists and C++ is still useful for it. But the “resurgence” of C++ really is a falsehood because that 10% case isn’t growing – we don’t suddenly have a need to write more highly-efficient code than was necessary ten years ago. And for those among us who look down on 90% of programmers who don’t know C++ as well as they do but are writing code for the 90% case in other languages… I imagine COBOL programmers once looked down on people too.
100% agree with John Sonmez. New C++ 0x11 is really very BAD,BAD,BAD language. As a John himself, i am total C++ fan. The main problem of C++ 0x11 is that it is very big and difficult to learn.
Good C++ programmer must know:
1) lowlevel things like what “register” / “restrict” / “auto” (old one) keywords stand for…
2) templates … Oh, crap. Int2Type/ StaticFactorial? I never used that stuff in production, but i have to learn that too!
3) good style: explicit/ virtual destructors/ exception-safety etc.
4) whole bunch of STANDARD libraries and classes: what was the last “you must use it” autoptr class?
4) new features like move semantics, initializers… Most of them are really “syntatic-shit” (as opposed to syntatic-sugar).
Why do we use copy-constructors? Why C++ has copy-constructors and other languages DON’T? Because of pointers. Most C++ programmers don’t understand that! You see? My class has about 80% of garbage-wrap-around-code and 20% of payload now. C++ 0x is not as clear as C++ was before. But “to-learn” stuff grows!
I really can’t understand why you folks don’t stop ADDING and ADDING new features. Yes we need new features, but main idea of your additions is “backward compatibility”. My opinion: you can never do something good without cutting off unneeded stuf! As long as old stuff is kept FOR TOO LONG TIME (for example 15 years) -> you are in big trouble. Stop doing things Microsoft way, remove features and stop supporting old stuff like Apple does.
For example:
What null_ptr is used for? Is it a real entity like functional langs has? I am sure -> no one will ever see that null_ptr would have other value than ZERO. Because of backward-compatibility…
“Old-C++” was a bad language too ), but it had something C++ 0x doesn’t … It was WELL balanced language. I used to learn to code Haskell and that language is perfect: it has clarity and is very expressive. Haskell’s grammar is about 1/10th of C++ grammar in size. Maybe that is the cause?
I would never suggest my kids to learn C++ nowadays. Let it be Python, C# or something else.
Beware the false dichotomy between “native code” and “managed code”. Sure the currently most used languages (C, C++, Java, C#, JavaScript) tend to make it true. It certainly is if you’re a manager who deals with C-syntax only programmers. But a more polyglot team can use Go, Lisp, or Haskell, all of which can compile to native code. In this case, your argument is quite weakened.
One can compile Haskell code and ship the binaries. It can therefore be tested as thoroughly as C++ compiled code.
Native code based runtimes tend to be much smaller, and much faster to start than a VM that must warm up (or even a simpler interpreter such as Lua). If your service consists of many short lived requests, a native garbage collected language is probably a good option. Your point stands when you need long-lived processes though.
Talking about cross platform usages of C++ i think Boost library, standard library and llvm based frontend CLang is doing a great work. It would be interesting to jit C++ also using llvm.
I do like C++ a lot, using it lately for some of my private projects (at work I use mainly Java/C#), after my employer started moving their projects from C++ to Java/C# in 2006.
Although I am quite enthusiastic with C++11 and the C++ renaissance, what I keep on noticed in all these discussions is that people continuously mix the languages with their implementations. There are native code compilers for Java and C#, but they tend to not be known by many developers.
If the language caretakers would start offering nice native optimized compilers for their languages du jour, the need for C++ would decrease in some scenarios where a VM based solution is not possible.
But of course, many of us C++ fans tend to ignore this possibility, as it would decrease the publicity for C++.
I am still looking forward to see C++ pick up speed so that I can convince my boss to allow some of the new stuff to get coded in C++ again, I just don’t want to wait 5 years to get some form of modules.
Does anyone remember how the computing world was 5 years ago and how the language landscape has changed meanwhile?
Whenever I code in C# I feel my brain cells die, and my productivity plummets. The language makes me feel stupid. Must be because it’s been designed as a lowest-common-denominator (corporate) language.
C++ on the other hand is a joy to code in. It makes me feel like an artist. I can produce quality code (ahem – my humble opinion of course) that is easy to extend and reuse. There are tricks you can do in C++ (for debugging, experimenting — using templates, inline code, dreaded macros) that aren’t possible without really struggling in other languages.
Yes it takes a long time to learn, longer to become skillful, but hey we’re fulltime pros here; it -should- take a long time to master your art. It feels great to wield skills that I’ve had to put a lot of effort into to learn.
I really would not like to code in an environment that is “upgraded” every couple of years. You’re continually chasing the “feature football”: Microsoft adds some spiffy new feature to .Net/C# which programmers then have to pursue like a pack of footballers chasing a ball around a park. In C++ it will take years for new, fantastic techniques we haven’t dreamt of to come out using C++11’s great new features. This can’t happen in C#/.Net’s continual upgrade spiral of obsolescence.
If some C++ code of mine isn’t doing what I want it to do, the question I need to answer is “What am I making the computer do?” There is a direct relationship between your source code and what the CPU(s) does to raw memory that represents your data structures. This doesn’t exist in managed languages, there’s a whole runtime that second-guesses your intentions and helpfully protects you from yourself.
Here is a bit of my thoughts on the post:
In general I believe,
1. C++ gives people(experts) opportunity to better optimize. So if you do not want the optimizations, please do not use C++.
2. I have always seen many people blame the language for bugs. It is not, with power there always comes better responsibility. So if people think they cannot take those responsibility, or control the raw power, then use other languages. Please do not use C++.
3. It may or may not be a general preference language. If you want to learn using a language in short term and start writing nice GUIs then please do not learn C++ or use it. They application written by impatient C++ programers is always used to abuse C++ in public forums.
4. Also in most projects I have worked (by the way i work on C a lot in beginning of career, C++ mostly, JAVA frequently, python occasionally) I have always seen few developers getting lazy and working without thinking of long term bottle necks. This always happens due to various reasons. So if you do not want to think the difference between List and Vectors, or you do not care about it, please use some other language, not C++. Still if you choose to learn C++ do not complain about the learning curve.
6. This may be my personal view, but i have always noticed that out of 10 people working in a very high level language, at least 3-4 gradually think only of short term results. They do not worry about the performance hogs. For example we have been using C++ in server side for last 8-10 years, but in the same time changed the front end language twice. Major reason is performance hogs. Its not the language that brings this hogs, its just the lazy thinking that “I will code as per will, let the language take care of everything”. This is the mentality that brings these hogs. C++ shows early failure symptoms when you code like this, other languages just forgive you till the customer becomes unforgiving.
5. You cannot write nice GUIs with C++ in a week, do not try to learn it to write GUIs.
6. C does not solve all the problems, nor is template meta programming or overloading complex. It just takes a little bit time, patience and effort to learn it and appreciate it. It does not come over night. In C you can write fast code, but in C++ you can write fast code that can be maintained better, and extended easily. If you do not want to think in OO or Functional terms do not use C++, use C.
7. If you learn C++ as a big brother of C, there is always chance you will suffer. Please learn C++ as C++, this will set the proper learning context in your mind.
That smaller, cleaner language you’re looking for is the one that is based on modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf), not 50-year-old compiler technology.
@Herb,
It seems to me that some of the dislike of C++ stems from its backwards compatibility constraints.
Bjarne said: “Within C++, there is a much smaller and cleaner language struggling to get out.”
Has there been any effort trying to define that smaller language in standard C++?
For example, say we wanted to deprecate C-style casts. Could we make them warn/error by default, and when using old headers or libraries, you need something like “#pragma allow_old_school_c++”?
A review of Jason’s work history on SO and linkedin, the lack of any publicly reviewable code or concrete examples of his work are all indicators that his commentary on the subject of C++ to be nothing more than hot air.
His biggest argument: Not being as productive in C++ when compared to other languages (C#, Java etc). Blaming the tool when not used properly, blaming the technology for not allowing you to reach guru status within 6-12months of trivial use, blaming the presence of complexity, when not fully understanding its existence – are all signs of a novice, inadequate developer.
Further more to preface each argument, with “I really love C++, but…” Is like saying “You’re a really nice person but…” Any technical debate that attempts to inject emotion or personal preference in lieu of properly thought through technical arguments and merits is also indicative of a lack of competence in said area of debate and more an indicator for a lust of self promotion and hot-air.
> There are other major reasons in addition to those, such as:
He forgot the most important one: Design without compromise.
As much as C++’s complexity may be seen as a disadvantage for newbies, it is giving the expert all the design tools at hand to express everything he wants directly, unlike any other “simpler” language.
C++ being good or not vs other languages… how many articles have been written about it?
I worked as a C++ developer for several years, now only C#
I wish there was a similar language to the C++(no intermediate language like in .net), having similar simplicity of the C# as a language(no OOP multi class inheritance language quirks) and being able to use the same framework awesomeness of .NET.
Thanks Herb. Good point about perspective. And I appreciate you attitude on the subject. We may not agree, but we can discus our different views in a productive way.
I learned a large amount about C++ from your excellent books and articles on C++.
@mrmcgibby great point! Rarely does any managed developer drop into the appropriate language like C or C++, myself included. We all need to be better polyglot programmers, using the right tool for the right job. :)
Decent article. I don’t think it’s *that* good. He makes some good points about the failings of C++, but he doesn’t really explain how some other language does it better. It really comes off as yet another post by someone who needs to prioritize development speed over execution speed, which is where all these “simpler” languages tend to shine. In my experience, these other languages execute fast enough on smaller projects, but start to break down on larger ones. The response is that you should write the fast parts in C when needed. However, this isn’t a trivial barrier and may seriously break the design of the system. These guys throw that approach around, but I don’t generally see many of them actually *doing* it because really, the barrier is pretty large.