The State of C++ – Is it Back or Not?


A few years ago when C++11 was published, people saw that C++ might be becoming a different language and a wave of enthusiasm got hold of the C++ community. “C++ is back!” was an often read sentence in blogs and articles. With C++14 out and C++17 and several TS on the horizon, is C++ getting back even faster? Is it getting back at all?

Some people, claim that C++ is not back at all. They essentially say that, while C++ is a great language, the new standard did not change the fact that C++ is a niche language for performance-sensitive areas and low-level programming close to the hardware.
The arguments are that C++ is not coming “back” because other languages are much better suited to manage the increasing complexity demanded by modern programs and that newer, simpler languages are better suited for the future than C++ with its complexity even increased by the additions made for the new standard.

A few weeks ago, there was a blog post “C++ in the modern world” by the team developing the static analyzer PVS Studio. I won’t go over the whole article here, but the punchline is basically that while C++ is alive and evolving, it won’t return to the glory of the (g)olden days before managed languages were a thing.

There is no going “back”

The notion of C++ coming back to where it was before the rise of languages like Java and C#, or even the comparison of C++ now and then has a serious flaw: It is an isolated view of only the languages, competing for popularity in a fixed surrounding.

In reality, that surrounding has been changing. Hardware evolved rapidly in the last decades, enabling the use of interpreted languages and JIT compilers in the first place. Back in the days of C++’s popularity, it occupied the same performance and low-level niche John was writing about. The difference is that the niche was all there was to computing.

With the new hardware, we got a host of new applications of programming. The range of things that need to be programmed has increased dramatically, for example, web development, mobile applications, and the cloud.

These are problem domains that have not been there in the old days, so it’s only natural that C++ was not designed for them and other, newer languages occupy those niches today.


Languages are very different and therefore are fit to occupy different niches. However, those niches are not discrete spots, and in between the extremes, there is a room where different languages may compete for popularity.

They compete in terms of language usability. When there are several languages to choose from for a given problem, there are several key considerations to be made. Usually, there is no single best language, and tradeoffs have to be made.

Among the important points are speed of development and efficiency of execution. Speed of development is where other languages usually outperform C++, due to the simplifications made, like automated memory management, more available libraries and better support in the IDEs and other tools.

When the sheer amount of hardware is not enough or not present, when it comes to memory or performance bottlenecks, we need the ability to go low level and do some fine-tuning. And this is where C++ still shines, and where it can’t come back because it never had been gone.

Current developments

While that performance and hardware niche is not really small, I think that C++ has some good chances to gain some ground in other domains. In the past and future C++ standards we have some good improvements in easier to write syntax and the number of standard libraries.

There are additions that aim to make C++ fit for the many-core age, and several working groups are working on support for features that have not been supported well in the past, for example, networking, game development, and real-time applications.

When it comes to tooling, I think that there are some promising tools emerging. In the past years we got dependency managers like biicode, several static analyzers and other tools like ReSharper for C++, and who knows what tools the Clang community is going to roll out in the future. I would not be surprised if there already is an IDE in the making stuffed with lots of useful tools based on those libraries.

C++’s niche in the future

There is another issue that could be a good chance for C++ in the future: Hardware restrictions. The size of problems that need solving is ever increasing, so the programs written to solve those problems will demand more and more computational power.

More computational power means more chips or more powerful chips. The chips themselves might be a problem someday, but the even bigger problem already today is the electrical power needed to operate those chips.

The “C++ in the modern world” article states that mobile platforms are already occupied by managed languages and objective C. However, the time may come when resources on a mobile device are an issue and having a VM running in the background in addition to all the apps managing our lives is just too much.

The same goes for cloud computing where facilities are consuming unimaginable amounts of power to heat up server rooms with our programs and cool them down again with their air conditions. Another market is the Internet of Things, where more and more embedded devices will need a language that delivers good performance, close to the hardware.

The performance niche C++ is occupying is growing, and so will be the popularity of the language. Maybe, if WebAssembly becomes a hit, there might even be C++ based web applications in the future.


I can not say for sure if C++ is a language of the future of if there will be another to challenge its place. What I know is that C++ never was dead, and it won’t be for a long time. Neither will it just sit there in its niche, because it is evolving faster than ever as the computational world is changing.

However, I don’t expect the adoption of the “new C++” to be as fast as with completely new technologies, because C++ has its history and there are lots of prejudices to overcome against a language that is conceived to be cumbersome and not simple enough. I disagree.

Previous Post
Next Post
Posted in


  1. For C, C++, Objective-C vs. C#, Java, Swift, the pros and cons seem pretty clear.

    You can write code that performs relatively few machine instructions more easily in C/C++/Objective-C, but you will always be aware of concerns like managing the boundaries and lifetimes of buffers. By the nature of the language, these concerns are never completely abstracted away. If you are writing “in the small”, with constraints on every side, those concerns are far from vestigial. Even in the large, if your task involves getting a bunch of data into your hand and then chewing on it – not unusual in code for EE, ME, and the sciences, then a language like this is ideal.

    If, on the other hand, you’re writing code that uses complex objects to coordinate complex interactions among a wide variety of technologies, the typical case with business applications on the desktop, the phone, and/or the web, being aware of what lies underneath becomes a distraction to a brain that is already getting quite crowded with competing concerns at a higher abstraction level. The evolution of managed languages is designed to push more and more of these “distractions” out of the way.

    In fact, a lot of work is ideally served by a blend, performing intensive analyses and communication and coordination, each, in the language suitable to the task.


  2. “If you want to build software that matters then use C++”


  3. I think the “come back” of C++ is also being fueled by the continued mobile push. C++ is great for sharing (at the very least) business logic between platforms. At my workplace we have begun sharing C++ code between Android, IOS, and Windows, and web.


  4. C++ still has opportunities to grow, as the IOT explodes with more and more things to program – but with cost compressing the choice of chips for each device. My refrigerator might use a high-level language … but the milk carton that talks to the refrigerator will use the smallest footprint possible – for both the chip and the programming language


  5. I develop large scientific programs for high energy physics, and C++ is BY FAR the language of choice. In particular, the major libraries I use (Geant4, CLHEP) are available only in C++; they are more than a million lines of code and represent hundreds of staff-years of development, by physicists. Code speed is a primary consideration, as some tasks require several million CPU-hours.

    I recently started a new program whose primary feature is a flexible 3-D graphical viewer. C++ has BY FAR the best library for that (Coin3D / Open Inventor).


  6. Hello all,

    I'm in the situation that I have to choose which part I will follow, I know the following languages: C/C++ and C#, the experience is somewhere beginner medium in the listed languages also I have know how about electronics electronic tools like programming tools, DMMs, oscilloscopes debuggers etc.
    I want to study and go deep into embedded and linux and for this side I have to go further with C and C++, so my problem is regarding to the C++ future, I readed recently 2 articles about the dark age of C++ and I'm afraid a little bit because I will start to go in details into a language which goes to die in the near future. What do you think it worth to start to go deep into C++ or I have to think about the language for embedded, architectures, linux?


    1. Like I said in the other comment, C++ is certainly not going to die in the near future. If the other languages are going to take over the embedded niche, it will still take some time. If you want to do embedded programming now, and if you want to do it for more than just fun or experimentation, I think there are not many alternatives to C and C++ in that field yet.
      Further than that it is not necessarily crucial which language you learn deeply, but it is crucial that you learn some language more than just superficially. In my experience, C++ is a great place to start, because if you know C++ well, other languages are much easier to learn, because the especially low level parts of C++ (or C) will give you insights about what happens below the surface in other languages.


      1. If you’re going into embedded you NEED to know C/C++ (but mostly C). All low-level register manipulations, drivers, timing, real-time constraints – you need languages that ensure that you’re in the driver’s seat and in control; contrast to other languages where you don’t know what’s happening under the hood, e.g. you’re in a funny Google self driving car, on a bumpy, dirt road. C and C++ give you that power, and they shine even more when programming in OpenCL. Embedded hardware is ever evolving, new hardware pops up every day. The amount of embedded cores and the complexity of the NoC (network on chip) inside SoC’s also changes a lot, requiring more stable languages that can handle heterogeneous multiprocessor programming efficiently and deterministically. Real-time control systems need perfect timing and it will never be accomplished by higher-level languages (because of their native non-deterministic behavior due to garbage collection, etc..). In the field of FPGA’s, you get to design your own system, and guess who has to write custom drivers for it? That’s right…

        With that said – C and C++ are painful langues – due to the fact that you have full control and freedom, that means you must take care of everything yourself, like garbage collection, drivers, libraries. The road is bumpy in the beginning, but once you adapt and become more and more efficient, you will learn to avoid simple mistakes like buffer overflows, null references and the sort. And even then, you will still face the same basic problems every day. There are good tools to analyse problems in C/C++ programs, namely SatAbs and CBMC to give a few.
        So by taking the embedded route, just always have this in mind, that you will be dealing with very basic problems every day, but in the end when you get your system up and running – you will feel satisfaction and rejoice. The reward you can get out of programming embedded systems with C/C++ is huge – you can safe power, operate the hardware efficiently and code size becomes much, much smaller – a MUST in embedded systems. And this will remain for years to come, in fact I predict that C++ will be augmented even further to more efficiently handle heterogeneous and multi-processor systems more efficiently, rather than going obsolete. There is a bright future for C++ my friend, and you make a good choice by learning it 🙂


      2. Thanks that’s avery clear argument for stayingwith C++ as the first language. I’ve started learning it a coupl of months ago by using “programming principles and practice” by Stroustrup which is a fantastic textbook to start out with this language. I like what you day about being too see what’s happening below the sur face of other languages like C#. I did some integrations with C# and I was left with the feeling of believing in magic.
        When creating databases with Entity Framework it was just clicking the mouse and voilà you just created one. It’s agreat language but a lot gets abstracted away from you.


  7. You are missing the big picture. Hardware is becoming smaller and has to run on batteries.This is why C++ is coming back because of memory and power constrains for smaller devices. There is no room to accommodate extra framework taking care of things and pay for it with additional memory and power consumption. Same applies to server side. It is cheaper to do it in C++ in the long run.


    1. Hey, he pointed up on the Internet of Things.


    2. Hi mk, that was my point in the section where I talk about the niche in the future: “the even bigger problem already today is the electrical power needed to operate those chips”.
      We have apps on small devices today running on C#, Java and other languages that use a VM or other framework, but due to the increasing demands on apps “the time may come when […] having a VM running in the background […] is just too much.”


  8. Nice post Arner, and I agree with you. But…, I think the new C++ has arrived at a time where it will find good competition in its own performance niche, from many fronts. We will be getting Swift from Apple, we have Rust from Mozilla, I would even include Go even though it’s garbage collected, also we’ve had D for a long time but it never got the same potential as this others got for a number of reasons.

    Everytime I think of C++ being used in new fronts I recall how affraid people are of it, like how people from Nasa prefers to use C (or C++ that’s almost C) for their mission critical applications. And I think, “well, that does seems like a good fit for Rust, since it’s safer.”. At the networking side when I write networking plumbing code in Go I think how natural the concurrent code is, and how performant it’s (memory and speed wise) despite it relying on Garbage Collection, which compared to networking latency turns up to be a minor factor several times.

    C and C++ are not alone anymore in the niche that has been left for their lasting glory. What I think is that C has the greatest advantage of this niche which is the binary interface protocol it provides (a language of it’s own). Like javascript is being targeted as a compile-to language at this moment in the web front simply because it has ended up as the lingua-franca of web browsers, C is the lingua-franca of native interop.

    In this aspect C++ is fragile language, and I don’t see people holding on it for writting operating systems and other hard-to-replace-the-language important applications. The performance niche C++ is being left with is solely because of it, not because of ABI lingua-franca or other reasons, maybe the other sole advantage I see in it is because it’s still somewhat ubiquitous through many compilers and legacy software, now.

    So I believe C++ may be going to suffer a slow death and we’re at the “last breath” phase.


    1. pepper_chico, the premises in your argument are relatives rather than absolutes — while they may be very accurate for your own experience, they cannot be used to make a sweeping generalization about the programming languages mentioned.

      Rust has its own ‘unsafe’ keyword that allows the programmer to introduce unsafe code to a code base and has behaviors that are unsafe but do not require the ‘unsafe’ keyword. These are mentioned in the documentation and include deadlocks, leaks from reference count cycles, failure to call destructors, signals, file system actions, and overflows.

      In fact, one could go as far to say that Rust does not offer more “safety” than using C++ with references. Using C++11 features this statement can be extended to pointers as well, which offers unique_ptr and shared_ptr to avoid manual memory management.

      Like any programming language, safety has less to do with the language features and more to do with how the language is utilized by the programmer (i.e. writing safe code). In any language there’s a population of individuals that will misuse its features and, unfortunately, this can’t be avoided no matter what degree of “safety” is claimed.

      The memory and speed you mention of Go is perplexing. Benchmarks have shown that Go, on average, takes at least twice as long as an equivalent C++ program. In a web or networking application, possibly this time has no cost, in other applications, such as a car’s emergency stop assistance module, this performance gap could be the difference between ending a person’s life or stopping the car in time. The memory aspect of your Go premise suffers the same conundrum, though with less outliers. Off the top of my head, the most widespread, recent language benchmarks are maintained by a member of the community (also covers many other languages).

      C++ is not, as you’ve stated, a fragile language, nor is it anywhere near its “last breath” phase. C++ is being used in embedded devices and “hard-to-replace-the-language” places precisely for the fact that it offers better performance and system options than the hard-to-replace language for a nearly equivalent cost. The evolution of the language in recent years has only increased its claim to a seat at the table.

      Bjarne Stroustrup, creator of C++, writes: “C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever.”
      “If you timidly approach C++ as just a better C or as an object-oriented language, you are going to miss the point.” (

      In my experience, the people that profess their dislike of C++ have merely written bad C code in C++, ended up with a code smell, and wanted to point the finger at someone other than themselves because “C++ is a better C.” More simply, the C++ standard committee’s website words this as “naturally you can write bad code in any language.”


      1. Sorry but your argumentation is orchestrating my text wrongly, painting a picture that’s the reverse of what I’ve said.

        I said Rust is safer, not mathematically fully safe. Nor did I endorse Go for the fields you mention (at last not for the time being), I’ve even added Go and D to this list trying to be ponderate. I did however (by the Nasa example) implicitly endorsed Rust for such fields, as it seems to me quite usable for such constrained places, given a good toolset is available.

        So if you’ve argued referring to Go for networking solely (as I did and you seem to have glanced over this as it was not an important aspect) and Rust for embedded and related (for whice I’ve provided a sample but you ignored and instead referred to Go for this…), I would be considering your argumentation with more seriousness.

        I expect not only Rust to enter this realm of computation, but other options will sure show up, and if C++ continues to be plagued with all the defects and complexities it offers, it may deserve to almost-vanish from it as it has almost-vanished from realms where it was once king. It’s evolution plain and simple.

        I’m a long time C++ programmer, I program C++14 at my job, coupled with other languages, but I look at it and have the same feeling a feel with some other languages like javascript: why make developer’s life much harder for sake of the language itself when there’re better alternatives or when we’re ready to provide better ones, when long time issues in the old turn into non-issues in the new.

        At these stage I’m towards/hoping for better engineered solutions/languages, not sticking with the old just because I happen to like to program in it. And I take this position because I know the amount of stuff I have in my head about the stupid inner-workings of a badly engineered solution, and don’t want people having to go the same route, people doesn’t deserve this, except the ones who enjoy pain 🙂

        That’s the reason I’m professing my dislike.


        1. Based on your 2 responses, I don’t feel I orchestrated your text wrongly at all — in fact, it is the points you’ve reiterated (proof by assertion?) that I addressed in my own response already. Rather than invalidating my argument, the content of your two responses have simply thrown more weight behind my own:

          On the topic of orchestration, your response concludes by rebutting my last paragraph which speaks to my own experience with people who profess their dislike of a particular language. I did not address your dislike in that paragraph at all — why would I? Your dislike of C++ is not a point I argued for or against, arguing an opinion is a moot point, so there is no need for further rebuttal on that.

          You say if I’d argued referring to Go for “networking solely” you would consider my argument “with more seriousness.” I did not simply glance over your point as if it were “not an important aspect” at all, I simply broadened the view from the scoped confines within which your argument was formed. I sought not to perpetuate the anecdotal fallacy born out of an isolated example — the saying goes: “problems cannot be solved with the same mind set that created them.” In fact, my example of a car’s emergency stop assistance module manages to fit in the category of networking quite easily. To accurately assist with stopping a moving vehicle, several exchanges must be made between several devices — any modern car is a small network encompassing several unique devices.

          Next, you argue a new point on Rust for computation. This was not a point I argued for or against — the entire basis of any operation in any programming language performs some type of computation. Neither did I make an argument for or against Rust in embedded devices.

          The point I made specifically about Rust can be summarized as follows: while Rust claims safety, many of the “unsafe” operations that occur across alternative languages can’t be avoided in Rust either — they are simply reintroduced by alternative means (allowing a programmer to use the unsafe keyword, unsafe operations that don’t require being marked as safe, etc.). Fun fact while on the Rust topic, the Rust compiler makes use of LLVM, which, in turn, just so happens to be written in C++.

          Nasa example? Your only mention of Nasa in the comment I replied to is as follows, take note this was used to support how “afraid people are” of C++: “people from Nasa prefers to use C (or C++ that’s almost C) for their mission critical applications.” Taking a look at NASA’s software projects, the statement you’ve made is fabrication at best. A premise based on false attribution simply can’t serve as a supporting example. They prefer to use C? In the NASA software catalog (, the number of current projects listed as being written in C++ to those written in C is 3:1. NASA requires strict standards for those that do include any C code, take the C Programming Language Coding Standard for the C code in JPL ( — many common practices in the C community are not even permitted in any of the NASA code base.

          The second reply you made raises the red herring argument proposing I simply did not “get” what you meant or misunderstood the entirety of your original remarks (for the second time). Then that same reply goes on to offer more proofs by assertion… I’ll have to stop addressing your responses here. I understood what you meant entirely, but the littering of logical fallacies used to support that very meaning obscures any accuracy that may have existed.

          My entire thoughts on this are best described in reference to your closing comments: you are “hoping for better engineered solutions/languages” because you “have in [your] head […] the stupid inner-workings of a badly engineered solution” to which I can only reply… a “badly engineered solution” is the consequence of a bad design. It’s easy to have a bad design but easiest to blame the tools.


          1. Sir, I think you should be smart enough to get what I meant by network plumbing code, if it’s not already clear in which space Go is competing with other languages now, it’s the realm of python/ruby/nodejs backend space, fyi.

            I could enter the philosophical discussion about how everything can be viewed as a network, but I’m not in the mood.

      2. “C++ is not, as you’ve stated, a fragile language, nor is it anywhere near its “last breath” phase. C++ is being used in embedded devices and “hard-to-replace-the-language” places precisely for the fact that it offers better performance and system options than the hard-to-replace language for a nearly equivalent cost. The evolution of the language in recent years has only increased its claim to a seat at the table.”

        I’m not sure if you got what I mean by “C++ being fragile” and “hard-to-replace”.

        I’ve posed C as one example of a language that’s hard-to-be-replaced for its niche, and niche that it shares with C++ (constrained environments, environment requiring performance, etc). But as I’ve mentioned C have other reasons for not being deprecated on such niches, C++ has much less reasons, and even worse C++ frequently acquires reasons for not being adopted in such niches, with itself to blame solely.

        So I say it again, it’s in this context that it’s fragile, because it can be discarded so easily as an option for new projects given that a better option comes up. Hence I stated that being the lingua-franca for ABI becomes an advantage. Over the time as it has happened to javascript, as it has happened to C, a context of dependency has been built that make such languages special. C++ has not built such context of dependency on itself over the time, it has no special thing that people relies and will rely on that other language can’t simply compete and even take over.


        1. What you say about C++ vs C is not even sensible to me.

          I have used C++ for a very long time. The only real disadvantages, without accounting for clumsy people making use of it, are: RTTI, exceptions (because of constrained environments) and a non-stable ABI.

          Make a stable ABI and please forget C, it will be less effective, no contest here. You can do with C++ what you do with C and better in every respect. You can go from the high-level to the low-level. You must know what you do, but that is why we are professionals, right?


          1. I forgot to say that with every compiler you can disable RTTI and exceptions, so these are not disadvantages except in one case: if you have libraries that could have been compiled without exceptions you will have a code size that is bigger.

            The commitee is aware of all these issues and they are working to fix it, just take a look at

            There was also a paper specifically about exceptions and violations of the zero-overhead principle, so that had also some research.

    2. Thank you for your thoughts! I agree that there are some competitors for the performance niche that have gotten some attention lately. I do not see much adoption by the industry yet, and I think we will have to wait and see who makes the race – one of the new and fresh languages or C++ with its inertia of billions or more lines of code already written.
      I would not give up on C++ yet, it’s an old beast and hard to kill.


      1. I guess it is going to be C++ inertia. Why is C alive, and Fortran? For the same reasons basically.


Leave a Reply

Your email address will not be published. Required fields are marked *