"Does C++ Have a Future?"

[quikquak]

If you're doing pure algorithmic stuff, then C# is about 12 times slower than C++ from my own experiments. And then you've got that f**king Garbage Collector to worry about!!!
As an example, Game engines may use C# or Java for the user to do their little games with, but the engine cores themselves are written in C++ for a reason!

[aciddose]

The most important thing about C (we're talking about C, not just C++, they're essentially the same language) is that the programmer has 100% control. "C gives the programmer the ability to shoot himself in the foot while in C++ he can blow his whole leg off."

This is absolutely essential for the majority of systems in the world. You may not see C and the C family of languages (a lot of the other languages discussed are actually in the C family too!) utilized most often on github or showing up in whatever metric is used. It is nonetheless the language used in computing.

Regarding C++, a lot of people make the mistake of confusing the language with libraries written in the language. For example: "C++ != STL."

When you look at the difference between alternative languages you see two things. Either one the language takes control out of the hands of the programmer "Those who give up liberty for security deserve neither"; or the language is merely another C family dialect.

"Perfection is achieved not when there is nothing more to add but when there is nothing left to take away."

If you look at what C actually expresses you will find that although there may be numerous other dialects possible with various trade-offs at play it is in its essence the absolute minimal practical language. See Turing-completeness for example in order to understand the only possible languages which are even more simple at the expense of practicality.

https://en.wikipedia.org/wiki/Turing_completeness

Knowledge about the origin of C++ is essential in order to understand what it actually is as a language. Essentially it can be summed up as being C with many layers of utility functions or "macros" designed to make the language easier to use as well as more reliable. In addition it has some minor changes (removal of struct, replacement with C++ class/struct) to provide OO capabilities as well as numerous more recent small adjustments.

So ultimately this is simply a stupid question to ask. It reeks of ignorance about what C actually is.

There would be no significant difference had the question been "does computing have a future?"

[syntonica]

Funny thing is, despite some important differences under the hood, c++ = Java = C# = Objective-C = Go = ...

Coming from Java, I got the gist of C++ in an hour and had the rest of it down in a week or two.

The differences in these languages, other than a few idiosyncratic orthographics, are pretty much memory management and type safety. Not sure what the current obsession is about type safety...

I originally choose Java for general purpose write once, run anywhere. Very nice feature and the JIT compiler does wonders with tight loops, which can hit speeds that rival C. But with 1.6, they just kept making the language worse and worse to where with 1.8, it just makes my eyes bleed... Instead of fixing Swing and putting proper closures in, they did something else they must have read about in the Necronomicon or something. So, I actually stuck with 1.5 and rolled my own on a couple of features from 1.6 that were welcome.

In trying to use the gawdawful built-in c++ classes, I kept running into the same issues I had with Objective-C/Cocoa/Java 1.8/etc. I can't work with manacles on, let alone a straight jacket. I ended up doing my own linked list in two methods, maybe 20 lines of code in all. It took me about five minutes to code, after I spent over an hour trying to figure out how to use the utterly useless List class in c++. Then I noticed that all the built-in data classes were the same way...

As a side note on fanboys, I used to work with this guy who went on and on about how great Haskell was. Finally, I took a look. And dude! It's Scheme! It's lazy Lisp! R-E-P... Nothing to see here... Move along...

[Winstontaneous]

The differences in these languages, other than a few idiosyncratic orthographics, are pretty much memory management and type safety. Not sure what the current obsession is about type safety...

As a side note on fanboys, I used to work with this guy who went on and on about how great Haskell was. Finally, I took a look. And dude! It's Scheme! It's lazy Lisp! R-E-P... Nothing to see here... Move along...

I think the type safety obsession comes from interpreted scripting languages on the web running into serious performance issues at scale.

It's interesting for me as a "developing" data analyst/web programmer (R, SQL, JavaScript, PHP) to hang out here in the DSP forum and then read threads on Hacker News where people complain about having to discuss memory management, basic data structures, and algorithms in programming interviews. It's clear that real-time audio DSP makes you confront these things head-on. It's also pretty impressive that C is still the foundation that most OSs and languages are built on.

Also worth noting that Web Assembly will now let you bring your C/C++ guns to the web coding knife fight.

[Mayae]

Specializing in C++ alone is dumb, yes - and any other language for that matter. You specialize in fields, stacks and technologies. Stacks and technologies usually define some ecosystem which you work with, and in other cases you simply just pick the best tool for the job.

C++ still has an indefinite future because there's nothing else that does what C++ does so well: Zero-cost high level features, language expressivity, control and arbitrary low-levelness, that usually can efficiently map most other DSLs needed in other contexts.

C++ solves a specific subset of problems that requires mentioned features. Desktop programming doesn't really in most cases - nor do (most) web applications. Some decades ago there just weren't really general-purpose languages, now there are plenty so the current trends are pretty natural.

[Guillaume Piolat]

C++ is dominant in many many high-performance niches (game engines, digital audio, digital video, codecs, HFT), many of which we haven't heard of.

I don't think it's because it was the only appropriate language for low-level that it killed its competitors at the time. Basically the whole Wirth family died: Ada, Pascal, Oberon... For example Delphi had inline assembly and was very much low-level aware, and compiled much faster . C++ unique selling proposition (meta-programming, absolute control and zero-cost abstraction) are at this moment also available in Rust and D: both have RAII, ZCA and deeper meta-programming at a minimum. Of course those new kids come with different trade-offs and culture.

C++ bigger advantage was by far being able to upgrade a codebase from C to C++ and get OO, so smoothing the transition over decades while people adapt (and let's be honest many C programmers haven't).

I'd say C++ domination became cultural and perpetuates through sociological effect because it's now legitimate. I would say in the same way classical-written music still attract top-level talent, while the contemporary composers must deal with the remaining performers. So the best libraries gets written in C++ (skia, chromium, etc). One has to remember that, once upon a time, using C++ was the heretic thing to do.

One underrated aspect that initially played against C++, and now works for it, is imho the ABI. Because of templates and complex object model, it is often only practical to use C++ libraries in pure C++ programs. To link with C++, you have to reproduce the same name mangling, and the same object layout. So the network effects are pretty high too at this moment.

[Mayae]

C++ bigger advantage was by far being able to upgrade a codebase from C to C++ and get OO, so smoothing the transition over decades while people adapt (and let's be honest many C programmers haven't).

You're right, this was a huge factor.

I'd say C++ domination became cultural and perpetuates through sociological effect because it's now legitimate. I would say in the same way classical-written music still attract top-level talent, while the contemporary composers must deal with the remaining performers. So the best libraries gets written in C++ (skia, chromium, etc). One has to remember that, once upon a time, using C++ was the heretic thing to do.

Perhaps, but these sort of arguments usually comes down to whether one feels C++ is fundamentally flawed beyond repair and/or evil.

C++ unique selling proposition (meta-programming, absolute control and zero-cost abstraction) are at this moment also available in Rust and D: both have RAII, ZCA and deeper meta-programming at a minimum. Of course those new kids come with different trade-offs and culture.

D and rust are very interesting. I'm not so sure about the D GC. Sure you can circumvent it but it seems to get really messy, and at that point I'm not sure whether you really gained anything from writing a lot of boilerplate code and amputating your language. My opinion is that C++ probably is the way it is because it had to be, but old-style C++ and the newer dialects are really also worlds apart.
There are other things on Rust that are not so nice in my opinion; error handling for one.

But as you said, different trade-offs and such (could turn into a huge discussion) - and all 3 are fast moving targets so it's hard to say anything definitive. I'm keeping a keen eye on them

One underrated aspect that initially played against C++, and now works for it, is imho the ABI. Because of templates and complex object model, it is often only practical to use C++ libraries in pure C++ programs. To link with C++, you have to reproduce the same name mangling, and the same object layout. So the network effects are pretty high too at this moment.

I wouldn't say it works for it, most general purpose libraries are still written in C just to have more compatible bindings.

[JoeCat]

For someone starting a career now in general I'd suggest that C++ not be the only language they learn, but if you are looking a specific niche (such as game engine development, audio applications, robotics, etc.), you'd do well to add it to your arsenal.

If you're leaning towards business / mobile / web development it certainly isn't necessary. It's still a great language to learn to really learn software engineering, like learning piano is a great way to learn music even if you intend your main instrument to be guitar. IMHO - If you learn C++ you come away with a much better understanding of other languages. Because so many things are explicit in C++ (parameters are pass-by-value unless you use a reference or pointer, for example), I think you'll find any other language quicker to learn. Another example is when I'm trying to figure out how another language works with arrays; I think I understand it better because I'm thinking in terms of pointers, etc., and what's going on under the hood.

I've been a C-based developer since the 80s. I do a lot of C# now, and it is much, much easier to use in general. However, my main job is developing software for scientific instruments, and for that, C++ is invaluable.

The biggest difference between C++ and other languages for most of the work I do (and something not immediately relevant to someone new to programming) is the availability of deterministic destructors (i.e. no garbage collection). Even on Windows (not a deterministic OS), it's difficult (though not impossible) to work around this feature (or "lack of a feature"!) with other languages.

I don't think it will ever be as popular as it was, but I think there will be employers looking for C++ developers for quite some time - I don't think another language will take its place for what it does, and while there might not be as many of those jobs, there will be less competition also (and I think jobs in industries outside of general business IT / Web can be much more rewarding).

I can't imagine doing VST / audio development without it, I just wouldn't make it the only tool in my box for career development.

[dasdeck]

You can write a library within c++ that basically transforms c++ into any other language, as long as you stick to that library of course. Just write a tool along your library to ensure that, and voila, you have all the benefit of a higher level language while having access to all the deep stuff of c++. Of course, you can vice versa, use a higher level language that is extendable through a c/c++ interface and reach the same goal. To my mind, it is much less about the language itself rather than about the available tools around it. Of course, some languages bring their own tool, so to speak, which in turn will influence its acceptance and create even more tools and so forth. So there you go, c++ can go on forever, depending on what we do with it!
I'm not following trends too much, so someone else could speak more qualified to that, so I may be annoyingly overgeneralizing here, but hey, even those trends take turns from time to time

[Guillaume Piolat]

I'm not so sure about the D GC. Sure you can circumvent it but it seems to get really messy, and at that point I'm not sure whether you really gained anything from writing a lot of boilerplate code and amputating your language.

I've written about this.
https://www.auburnsounds.com/blog/2016- ... ntime.html

You can circumvent anything, in particular for plugins it made no real difference to run with the D GC in UI treads only vs removing the GC altogether (what I do now but for macOS compatibility and memory usage reasons, not perf). In D the GC is "atop" the otherwise RAII destructors of stack objects. It calls destructors for heap objects but really should not even try. Makes the whole story harder to explain that C++-style resource management (which is possible, just not what happens by default) and those non-deterministic calls produce accidental correctness.

Fortunately D has imho other things going for it.

[Zaphod (giancarlo)]

Funny thing is, despite some important differences under the hood, c++ = Java = C# = Objective-C = Go = ...

Coming from Java, I got the gist of C++ in an hour and had the rest of it down in a week or two.

The differences in these languages, other than a few idiosyncratic orthographics, are pretty much memory management and type safety. Not sure what the current obsession is about type safety...

I originally choose Java for general purpose write once, run anywhere. Very nice feature and the JIT compiler does wonders with tight loops, which can hit speeds that rival C. But with 1.6, they just kept making the language worse and worse to where with 1.8, it just makes my eyes bleed... Instead of fixing Swing and putting proper closures in, they did something else they must have read about in the Necronomicon or something. So, I actually stuck with 1.5 and rolled my own on a couple of features from 1.6 that were welcome.

In trying to use the gawdawful built-in c++ classes, I kept running into the same issues I had with Objective-C/Cocoa/Java 1.8/etc. I can't work with manacles on, let alone a straight jacket. I ended up doing my own linked list in two methods, maybe 20 lines of code in all. It took me about five minutes to code, after I spent over an hour trying to figure out how to use the utterly useless List class in c++. Then I noticed that all the built-in data classes were the same way...

As a side note on fanboys, I used to work with this guy who went on and on about how great Haskell was. Finally, I took a look. And dude! It's Scheme! It's lazy Lisp! R-E-P... Nothing to see here... Move along...

There is an abyss between c++ and java. You'll realize it as soon as the number of code lines and linked libraries will increase. I would say a giant project in java is still "simple" to maintain. Yes the syntax is almost the same. But as soon as something is wrong in c, the nightmare will begin and you'll spend a lot of time on debuggers
Java for me is extremely relaxing

Among complexity factors

- Compiling time
- Resource races in multithreading applications
- Faults in external libraries


Java starts being hard again as soon as you use jni and other native approaches (and you get "crashes" again)

[aciddose]

My experience with Java has shown them to be identical in this respect. If you were to add third party Java libraries you'll run into exactly the same problem. So this is really apples to oranges and when you try comparing apples to apples or oranges to oranges things look a lot more similar.

One major difficulty with Java is that anything large scale in terms of data processing or management of complex hierarchies of objects quickly becomes a major memory and scheduling issue with completely unpredictable GC and heap performance.

In C++ you have the ability to manage allocation yourself which opens up the possibility for you to design the code from the beginning to avoid such problems as the scale of the application increases.

Java unfortunately takes this control out of the hands of the programmer and says "here, we'll manage types and memory allocation for you! Also we think it's a great idea to run with a mystery GC performing unknowable tasks in the background!"

I'm not sure if you're aware but in many sectors such as health, aerospace and military/defense dynamic allocation is absolutely forbidden as in DO-178B/C for example.

In those places Java is completely off the table.

[kmonkey]

One must be a moron to believe or expect anything video say.

It's like saying can we expect doomsday because every book mention it. Yeah in theory we can.

[Zaphod (giancarlo)]

My experience with Java has shown them to be identical in this respect. If you were to add third party Java libraries you'll run into exactly the same problem. So this is really apples to oranges and when you try comparing apples to apples or oranges to oranges things look a lot more similar.

One major difficulty with Java is that anything large scale in terms of data processing or management of complex hierarchies of objects quickly becomes a major memory and scheduling issue with completely unpredictable GC and heap performance.

In C++ you have the ability to manage allocation yourself which opens up the possibility for you to design the code from the beginning to avoid such problems as the scale of the application increases.

Java unfortunately takes this control out of the hands of the programmer and says "here, we'll manage types and memory allocation for you! Also we think it's a great idea to run with a mystery GC performing unknowable tasks in the background!"

I'm not sure if you're aware but in many sectors such as health, aerospace and military/defense dynamic allocation is absolutely forbidden as in DO-178B/C for example.

In those places Java is completely off the table.

It depends on complexity and size of the project. When you are working on a big project with thousands of libraries involved and you get a "crash" they are not the same, at all.

[BertKoor]

Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it! Which programs are fast? Which are succinct? Which are efficient?

http://benchmarksgame.alioth.debian.org/