Reader Q&A: “Will C++ remain indispensable…?”

C++ 2 Minutes

A reader wrote me today to ask the following. Since this is a FAQ, I thought I’d post the answer here.

With the advent of C++11 and upcoming C++14 and C++1y, the language has strapped much of the digital electronics industry under its belt. High performance software, Libraries, Embedded, Research, Web backends, our everyday software, and trivial systems; Everything directly or indirectly depends on C/C++.

My question is -: Will C++ remain indispensable for creating above mentioned class of production software for very long foreseeable future ?

Short answer: Yes, but don’t stop there because that’s not all of what C++ is about!

Expanding on “Yes”: Yes, I think so. The main reason is that several long-term industry trends now in progress favor C++’s core strength of “efficiency per Watt/cycle/transistor + full flexibility and control” in a portable language. For example, for mobile (notebook, tablet, phone) and cloud datacenter (Facebook, Google, etc.) app environments, both of which are clearly large and will continue to experience long-term growth, the critical measure has already switched to “performance per Watt”… if that’s your primary constraint and cost, you’ll usually end up at either C or C++, and the latter gives you stronger abstraction. And performance per Watt is just one example; besides that one, as other trends like the power wall and the eventual end of Moore’s Law continue to grind out, the value proposition of “performance per Watt/cycle/transistor + full flexibility (to express what you need) and control (over hardware and things like memory layout)” will remain valuable in the long term.

Expanding on “but don’t stop there because that’s not all of what C++ is about!”: Old C++ used to be harder, but today modern C++ is far from limited to those categories. As I pointed out my “One C++” talk last week (start around the 42:00 mark), C++ is already a de facto standard language to teach artists (not professional programmers) in the world’s top design schools such as Parson’s, notably using C++ plus the openFrameworks library, and C++ is also a widely used library outside schools for creative interactive applications (again often by people who are not programmers by training), notably using C++ plus the Cinder library.

Other languages are important and useful too, and often are built on top of C++, and that’s great – there is no such thing as “one language fits all,” and everyone realizes that like any language C++ is not for everyone or every use. Nevertheless, C++ is very horizontal, meaning usable in many domains, and the cases where C++ is applicable and actively used is growing, not shrinking; one effect is that we have to relearn what a “C++ programmer” is because that group is getting increasingly diverse. As we continue to make C++ more accessible, I expect we will continue to hear about its being used more and more even by people we didn’t expect, like artists and financial gurus who are not programmers by training and whom we never used to think of as C++ programmers… it’s happening already.

Published by Herb Sutter

Herb Sutter is an author and speaker, a software architect at Microsoft, and chair of the ISO C++ standards committee.

Published

24 thoughts on “Reader Q&A: “Will C++ remain indispensable…?””

  1. @Tim

    Good languages need good forums. One big unnoticed achievement of C++11 has been improving the quality of the online discussions. The recent C++11 conference and video tsunami may have also contributed.

    You say Garbage collection can be disabled in D. I have read this often but no clue what it means. I can write my own standard D library that does not use GC? Great! So I stopped reading D language forums. I will check in a year or so again to see if quality improved. After all, Alexandrescu is amazing (hopefully Herb will not read this)!

    But even Alexandrescu is talking more C then D lately.

  4. @pjmlp: Yes. He is smart and a good guy, but so negative that I wonder whether we were at the same conference. He’s welcome to his opinion, and many people have said the same; but I don’t share it, and I disagree with most of his examples.

    Two particular things he’s wrong about involve compatibility:

    1. He underestimates the importance of source backward compatibility. It’s extremely important, see here: https://herbsutter.com/2012/12/04/compatibility/

    2. He overestimates the complexity cost of source backward compatibility. It isn’t as high or important as he thinks.

    I’ll talk about this on Tuesday night in Chicago at the Chicago C++ Users Group meeting: https://sites.google.com/a/chicagoacm.org/chicago-chapter-of-the-acm/meeting-topics/2013-09-24-onec-herb-sutter (Note it says the event is at capacity, but they’re looking for a bigger room, so do add yourself to the waiting list.)

  6. Matt: Clang (and other tools) is getting really good at detecting undefined behaviours and unwanted memory accesses in debug builds. There is also a lot more emphasis on defining what standard behaviour should be in C++, and for compiler vendors to follow it. I think this the “one C++” thing Herb talked about, but I haven’t got to that video yet in my Going Native binge :). Lots of great work being done by Herb and others at the moment, thanks!

    Programmes operate on data in memory. C++ is a “real” programming language while others aren’t as far as I’m concerned because it lets me tell what the computer to do with that memory, without fuss. I don’t like working in languages that think I don’t even know what a pointer is.

  8. I think it’s dangerous to promote C++ as a general-purpose programming language today, because C++ is not memory-safe. For the vast majority of code, we should use a language and runtime environment that provide a solid bedrock of abstraction, so that things like buffer overflows and stack smashes are simply impossible. Aren’t JIT compilers good enough now that we can relegate C++ to the last resort for the small amount of code that where performance really matters, rather than the first choice?

    See also:
    http://wingolog.org/archives/2011/10/13/whats-your-c-migration-plan
    http://www.loper-os.org/?p=55

  9. It *should* be a silly question to ask if the main industrial-strength language that emits fast native code has a future. Otherwise, what’s the point of CPU manufacturers continuing to strive to make their chips faster and use less power?

    But here is the sad reality.

    The “critical measure” for writing code for server systems (besides the sector Herb mentioned) isn’t speed, it isn’t power efficiency, and it isn’t even programmer productivity. It’s programmer salaries. This is the overriding concern of the employers of most professional programmers today. Large companies might think they care about productivity, but to them driving down salaries is more important. Look at modern trends, and look at the FizzBuzz phenomenon to see how much value is really placed on competency.

    As for mobile platforms, C++’s benefits are even less important. The “critical measure” is getting your stupid (cr)applet out to as many tablets/phones as possible. Herb himself linked to an article a couple of weeks ago showing the dire state of the mobile ecosystem. Who cares if your finely-tuned, well-written app can run for ten hours straight if there are ten other dodgy apps that have killed the battery long within that time? This isn’t even an important issue, more urgent is how many apps that leak credit card or login details to the outside world in plaintext. Fast mobile code doesn’t matter even to OS developers, a guy wrote his own jpeg coder in C and assembler that outperform’s Apple’s native one for an app that can take lots of hires photos rapidly.

  10. Until a language/technology have some advantage over others, it will survive. And C++ have a great advantage: the performance and this is a continuous demand, no matter how fast the processors will become. I like Java/C# languages, but C++ it’s still my prefered.

  12. Great post folks! Having experienced the birth of OO and the migration to C++,from Assembly to C and reaping the benefits of abstraction and ease of use of well designed interfaces and contracts. You should take a moment to thank K&R and Bjarne for building a discipline which has remained a solid foundation for many of the modern languages that focused on safety and ease of use as opposed to pedal on the metal power.

    Are Fortran and Cobol still in use ?

    Use the best tool for the job!

    The customer only cares if it is delivered in time, on budget, and is supportable for the perceived life of the product range.

    Java is cool, but its not C++, C++ is not C, but its not Assembly language, Assembly Language is not machine ops,
    write code in zeroes and ones, if your not capable to re-architecture the silicon.

    Make money, and always write code as if you are going to die tomorrow and someone else has to take it over, in whatever language you like, as long as it’s English!

    SW.

  13. @ Jon

    “I’d love to see a language that had all the performance of C++ but much of the productivity of C#”

    Jon,
    What is the productivity of a procedural language?
    I assume the productivity of C# will come along after the answer above.

  14. Sutter, I enjoy reading your articles. It always gives me hope of one thing: That C++ will be used in software factory companies. I mean those companies that need to build good software products in a short amount of time.

  15. @Herb: Since this is my first comment on your blog, let me start by saying that I’ve been watching your talks for a long time now, and I’m a big fan of yours. You are one of the few people whose presentations are easy to understand and fun to watch, despite the complexity involved.

    You already were very clever in saying “but don’t stop there […]”, because being simply “indispensable” is obviously not the real question here when considering that even things like the linkers & loaders “crowd” are still very much indispensable today. Yet that specific field (and others like it) despite being absolutely crucial for the continued existence of civilization as we know it, still remains an arcane art, for all practical purposes, for most of us, and entering the field is not a viable career option (unless you already happen to be the son of linker author or similar..). Similarly, how many of us will really end up working for Google/FB/etc. in that kind of capacity?

    The real question is what portion of developers will still be writing C++ 10 and more years from now, or for what portion of projects C++ will be the first choice 10 years from now, and so on. You already tried to answer this a bit with the “100 years from now” question on the panel at Going Native 2013, but that obviously was a bit too futuristic.

    Also note that this is not about how many C++ developers or projects there will exist in absolute numbers. I remember someone claiming that there were more Assembly programmers around today than ever before, simply because there are more developers in total around today than ever before. But of course the relative share of Assembly programmers today is nothing like what it was 10 and 20 or even more years ago.

    You said in your answer “C++ is getting easier”, and while I agree with that, I still think that Andrei was right on this, when asked during GN2013, when he said that a C++ beginner will be simply lost on the first compiler error that he’ll see, because the error will contain all sorts of notions that he knows nothing about. And even if the compiler error isn’t enough of a hurdle, then the first runtime error surely will be, because the C++ abstractions simply fade away during compilation and there’s nothing like a stacktrace to help you out when things go sideways.

    To give some context, I’m a fairly young Java developer looking to get into C++ since Java feels a bit dull (which is not to say it doesn’t get the job done). As such, I have been reading the C++ Primer and my impression of it so far has been that each new page unveils new horrors. Bjarne said if you know int and vector you know C++. Someone joked about the complexity involved in vector during the panel later, but the really scary piece is that a lot of people don’t even know int. And how could they possibly, considering that both size and semantics of int are implementation-defined? And that’s still leaving out things like unsigned and overflow.

  16. @Matt: Actually Bjarne’s auto/decltype proposal included auto parameters for implicit templates. That’s likely to still come back in the future. However, C++14 does already allow auto for parameters in lambda functions, so this is legal C++14 and actually often better than a hardcoded type: 

    [](auto& coll, auto val){ coll.push_back(val); }

  17. @Dain, I think the problem with this is that the problem with auto as a parameter like that is that C++ still only allows a single parameter type for a method. If you used auto to support more than one type, then you would be generating multiple methods, which is a bit surprising since it’s not a templated method. The alternative is for the auto to try to find a type that is implicitly convertible to from the types of all parameters that it is called with, also a bit surprising.

    Maybe I’m just missing something obvious, but with auto return type, you can easily deduce return type from what is being returned, and it will always be the same. If you want auto to work the same as a templated parameter type, I don’t see how to always generate a single method, and it seems odd for it to generate multiple methods.

  18. @Jon, take a look at some of the languages mentioned here:
    http://parasail-programming-language.blogspot.com/2013/04/systems-programming-with-go-rust-and.html

    Neither ParaSail nor Rust require GC (it’s not needed for memory safety, it’s not sufficient for general resource safety anyway, and it introduces unnecessary run-time costs — to be honest, I’m not sure why there are “modern” programming languages still being invented that keep dragging this invention from over half a century ago to the current day and age).

    http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/
    https://air.mozilla.org/region-based-storage-management-parasailing-without-a-garbage-chute/

    // As for Go, let’s forget about Go ;] Personally, I’m just not that impressed by it–I don’t find sufficiently many reasons compelling enough for it to be even a potential contender in the systems programming category.

    BTW, @Herb, I’m wondering what are your thoughts on these?

  19. @Jon, “I thought the D language and Google Go might be attempts in that direction but they both use garbage collection by default, which appears to favor productivity over performance. Do you think such a language is feasible?”

    Garbage collection can be disabled in D.

  20. In my opinion, there are great progresses to be made on the teaching side. Do you know what is the #1 reason for C++ expanding to non-professional-developers ? The accessibility of a free online course for beginers (i learnt C++ this way, did not pay anything for learning it). There is no such thing like that for C++11 yet, that’s why although i just love C++11 and think C++98 is deprecated, i’m still forced to recommand a C++98 course (sadly not even modern style :/ ).

    On my side, i’m going to try to do something (in french sorry, language accessibility is also really important !) for that, i think it’s really worth it. Something not the book way, because lot’s of online courses are written in a style for books (because they aim to become a published book, or are taken from a published book), and it’s not really adapted to the web’s way of learning.

  21. I really enjoyed the presentations done at Going Native this year.

    Let me also thank you for making us aware of openFrameworks and Cinder, they are really nice.

    What I think might be an issue with C++11, C++14 and the still very far away C++17 is how far away some of them still are. Not to mention the C++ style guides most companies tend to have.

    A year in computer time can mean many changes, let alone the time until we get stuff like modules into the language and mainstream compilers.

    This will leave the door open to other languages with native compilers that are good enough for the same type of tasks C++ is good for. It is already happening, actually.

    Here I agree with Andrei Alexandrescu, even C++14 will require developers to know archaic C and C++ stuff when problems arise.

  22. @Herb,

    I’d love to see a language that had all the performance of C++ but much of the productivity of C#. Whenever a trade-off had to be made, it would favor performance over productivity.

    I thought the D language and Google Go might be attempts in that direction but they both use garbage collection by default, which appears to favor productivity over performance. Do you think such a language is feasible?

  23. I think the advantages of C/C++ truly shine in software with clearly defined, scoped, and relatively static requirements and responsibilities. When requirements are not a fast moving target, C++ allows the programmer complete freedom to exploit the hardware to, as you said, maximize performance per watt, while still maintaining levels of abstraction that allow for readable, reusable, and maintainable code. And I think this is why C/C++ is so prevalent in software that most of us use: such software is likely to be established and mature (traction takes time), and as a result, its designers and programmers have had time to nail down the main user scenarios and come up with a performant and extensible architecture.

    The key here is time: C++ allows programmers to exploit the hardware, but doing so introduces complexity into the language which means that developers need more time to think through the design, which can only happen when requirements are not quickly changing. These conditions happen to be true for many software systems that we all use such as operating systems, browsers, libraries, etc. But there are also a world of applications out there that are only used by a relatively small team of people, in domains where requirements are quickly changing, iteration times are fast, and product/market fit is the main challenge as opposed to performance. I think that in these types of situations, managed/interpreted languages will always remain more suitable than C/C++ due to the increased developer productivity they offer.

    tl;dr: C/C++ will remain indispensable for high performance, mature, and established software with clear requirements, whereas managed languages will remain indispensable for developing prototypes and software with uncertain or changing requirements with quick iteration times.

  24. Hi Herb I was looking at the C++ 14 language additions and was surprised that it doesn’t appear that you can use auto in normal function params?

    Like:

    struct Object{
    auto Func(auto i){ return i;} //<– better, but not possible

    template
    atuo Func(T i){return i;} //<– pointless extra typing to express the same thing :(
    }

    They appear to have added auto return types, and auto for generic lambdas though– how did this part get missed(or did it?)?

    I realize that this is basically forcing it to act as a template(header only implementation?), but the terser syntax seems very desirable..

    Thanks!

Comments are closed.