[everheardofc]

C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features. The only thing you cannot change are implicit defaults (e.g. pass by value is the default, you have to manually opt out to pointers or references).

I like modern C++ because for me it's a reasonable compromise between java safety and C safety. Other than out of bounds memory accesses and legacy code I feel there is not much that can go wrong. However compiling C++ projects takes ages and in the projects I've worked on I often have to modify headers that are included almost everywhere. Every trivial changes requires a 5 minute rebuild.

After working with several high level programming languages with slow compilers I realised the following: typing is fast, compiling is slow. There is a reason why go is so popular. It offers that tradeoff in fast turn around time / compilation time with reasonably good performance and simplicity in exchange for more keyboard bashing and keyboard bashing is a cheap price to pay for what you're getting back.

[staticassertion]

> C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features.

I feel like C++ proves exactly that you can't.

[eslaught]

> I feel like C++ proves exactly that you can't.

Depends on what you mean. At a minimum, I think it's clear that C++ has avoided a Python 2/3 style split in the community. This means that otherwise relatively conservative users (I'm thinking of users on supercomputers in this case) are upgrading quickly to new C++ compilers and standard versions.

On the other hand, C++ has always been a kitchen sink sort of language, and it is even more so now. As codes age, they tend to grow and not shrink in the feature set they use, and so long-lived codes will probably never completely escape the demons of previous versions, regardless of how nice the shiny new features are.

[dzdt]

Lol. At my work I am still eagerly awaiting the arrival of C++11.

[EpicEng]

That's not the point. The point is that, when you get it, you won't encounter a list of breaking changes and your code will continue to work.

[ernst_klim]

>you won't encounter a list of breaking changes and your code will continue to work.

Sure, that's why my gstreamermm app refused to build when I switched to --std=c++17

[EpicEng]

Here's the list: https://stackoverflow.com/questions/6399615/what-breaking-ch...

Was it one of those? If not then the fault was with your code or the implementation, not the spec. The language itself is very good at maintaining backward compatibility.

[candiodari]

If C++ is so bad then why:

1) are 90% every really large software projects written in C++. All the programs "everybody knows" just happen to be in C++. Examples include Chrome, Windows, Microsoft Office, Adobe tools, KDE, Autodesk, ...

Clearly those programs have massive scopes, large complexity, the need for extensive abstractions, the need for large teams cooperating, tests, ... all the stuff we value as programmers.

2) Are all programs in most other languages so ... small. In scope, in features, in ... Just look at Go programs on github. Or python ones.

Very large Python projects are a few 10's of thousands of lines of code. And they are limited by their complexity. Somehow C++ programs seem to have less of this problem.

Very large javascript projects don't even seem to get above a few thousand lines of code. And reading them, I can see why. Typescript at least seems to match Python in how much complexity it can contain without imposing too much of a burden, but that language doesn't match C++ either.

Most of those fancy languages are artificially limited in some ways. For instance, you cannot easily link QT into Go (nor can you do that with many other libraries, GTK has the same problem). C++ does not have that problem, and if it does, you can solve it. I do not claim doing so is easy, but it can be done. You're not stuck. Go on IOS ? It sort of works, with a boatload of limitations that make it utterly unworkable. C++ on IOS ? It works, with less limitations than Objective C.

I feel like C++ gets a much worse reputation than it deserves. Much worse. It is not the solution to everything, of course.

[sgift]

1) I know so many programs which are the same size or bigger than your "well-known" programs you probably never heard of but still use daily - They are just not desktop programs, a place where C++, for various reasons, is often the language of choice, but desktop programs are (for better or worse) just a small subset of all programs written.

2) See answer above.

> I feel like C++ gets a much worse reputation than it deserves. Much worse. It is not the solution to everything, of course.

In the end it all boils down to Stroustrups quote about programming languages: 'There are only two kinds of languages: the ones people complain about and the ones nobody uses'

[mathw]

Point 1 is mostly down to history I suspect. The big Adobe stuff is in C++ because they started writing them when C++ was The Thing. Probably quite cutting-edge then (not that it doesn't have some cutting-edge features now of course, that's what makes C++17 and C++20 and so on worth watching). Windows, Office likewise, although I've always assumed that an increasing chunk of Office is now written in C#. I have no evidence of that by the way. KDE - again of its time. Autodesk, likewise.

And then that gives you a huge historical inertia. Chrome started out using KDE's rendering engine, which was written in C++, at a time when writing cross-platform GUIs wasn't really feasible in anything else if you wanted it to also be reasonably fast.

And they stay in C++ because changing languages is a right pain in the whatsit, and C++'s ABI is so variable across platforms and compiler versions through history that integrating components in other languages is often not worth the effort to maintain. Not that it hasn't been done, of course, and done well. Look at how Firefox are now integrating Rust components in their C++ codebase - although they're doing it by relying on Rust's ability to expose a perfect C ABI, and C++'s ability to call it.

Point 2... yeah. I get this. C++ has a higher complexity bound than many languages, especially dynamic ones. C++ used as C++ rather than C-with-classes has a strong type checker and some very robust capabilities around memory management, program integrity, metaprogramming (even though the syntax is dire and the compile times are horrible). C++ expertise in large software construction is widely available. C++ will compile down to efficient machine code that runs well on many platforms. These are all huge advantages in large projects.

Python has its troubles with concurrency, and the lack of type information in the source code to help maintainers. Go is just too young - I suspect we're going to see some really giant Go projects emerging over the next ten years, especially outside the space you can see on GitHub. There will be big enterprises deploying enormous Go codebases, although they'll likely be made up of multiple components instead of one giant thing like we used to do. Rust's too young, Haskell's got the chops but is too weird for most people (and its own problems, although Stack has really helped with the developer experience), JavaScript is entirely unsuitable to a large maintainable codebase. I'd guess TypeScript can probably go a bit further then Python in that space, at least until Python's new type annotations start getting fully checked by tooling at which point it returns to parity (or exceeds it, due to not being JavaScript in disguise. Guess what, I don't like JavaScript, who'd've thought!)

But still we've got C++'s inertia to thank for a lot of this. It's huge, it's old, it's still being developed and still being used and there's a lot of knowledge and a lot of capability out there.

But then look at newer disciplines. Look at mobile apps - yes you can write C++, but the native languages of Android are Java and Kotlin, and of iOS are Objective-C and Swift. What are new developers going to want to do - learn Kotlin and Swift or figure out how to shim C++ into those platforms via the variously awkward methods available?

What about the web? How many web applications are written in C++? Very few, I suspect. It's all C#, Java, PHP, Node, Python and other modern things which may or may not be considered sexy.

C++ dominates in the older disciplines, the older software that's still here and we still use and will use for a very long time.

I think elsewhere it's being passed by, especially as we get languages like Rust and Go which are considered as possible replacements in the "I really need this to go as fast as possible" camp.

It's a shame really, as C++ is still a powerful, impressive language and the new stuff is fantastic. But I always felt when I was working as a C++ developer that I wished I could turn off those C-compatible core behaviours and completely block those implicit-but-dangerous type conversions, and get the compiler to scream at me about dangerous pointer usage (I believe something along those lines is in the works for a future standard).

And also a shame about D, which has its followers but has been largely ignored, overshadowed by C++ to start with and later passed by the new languages which get all the hype.

[moomin]

It definitely can't solve the problem that the language is hard to understand:

https://www.google.co.uk/amp/s/akrzemi1.wordpress.com/2013/1...

[ksk]

C++ is a tool for low level systems programming. Why would you compare that with GO? Also, I would argue that C++ is _WAY_ more popular than GO. It allows you to be productive in the real world, utilizing legacy code, legacy libraries, APIs, etc. Very few projects are 100% greenfield.

[iamnewhereqwer]

Many desktop apps are still written in C++.

[copx]

"Many" is an understatement here. Pretty much every Windows desktop app is written in C++ and Windows runs on over 90% of all desktops.

Adobe will never rewrite Photoshop in Rust or whatever. If you thought burying COBOL was hard.. C++ will outlast humanity.

I can already hear the Alien scientists: "An amazingly intricate and convoluted language for such a primitive species. The mismatch between their mental abilities and their language might explain the bug which caused the incident.."

[pjmlp]

As someone that has spent quite some years writing Windows software, actually since the .NET introduction and the maintenance status of MFC, the majority of Windows desktop apps are written in a mix of .NET and C++.

[rxhernandez]

> Pretty much every Windows desktop app is written in C++ and Windows runs on over 90% of all desktops.

I think you may be the one overstating things. Where I work, a biomedical device firm, for every one app written in C++ there is either one python or matlab prototype of it and 5 python/matlab apps to test it/show it off. I'm sure for other places that number is far higher. I honestly don't see how you could quickly prototype sufficiently complex ideas any other way.

Better said, I can build a working Kalman filter, load saved patient data to it, create a primitive db, save output data to said primitive db, build a primitive, but functional enough that non-technical people can use it, GUI, from scratch, to plot said output data in Python all in a couple hours. Can you do that with C++ for the same time frame? Heck can you do it within an order of magnitude of the time I used? If you can't, why should you be spending an order of magnitude more money for it?

[staticassertion]

You wouldn't have to rewrite Adobe. You could rewrite one component of it (0 cost FFI). That's fair more reasonable. I think Servo is proving that Rust has a lot of potential for slowly replacing a C++ codebase, piece by piece.

[pjmlp]

On Windows, Rust still has the problem that it needs to be as easy as C++ for working with COM, specially now with UWP.

[tonyedgecombe]

Is anybody using C++ with UWP? I would have thought the obvious choice was C#.

[ksk]

Sure, people will ultimately use the tool they think is right for the job, given the people they've hired, etc. C++'s strength isn't UI programming (might be generalized to things that require more input from designer's than programmers), but writing high-performance, low-abstraction code (which could very well be the dominant factor in the success of the desktop app, hence the choice).

[flavio81]

>C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features.

Well, "adding more features" can't be done "simply" if you want to "maintain backwards compatibility"; indeed, in the process of doing this is that the "flaws" are potentially augmented.

[pjmlp]

They also have removed features that were deprecated in C++11 and C++14.

[humanrebar]

Yes! These are underrated items on the change list. Establishing precedents and habits for removing harmful things (like trigraphs) is very important to the future of the language.

[gcp]

There's some funny ones there. std::random_shuffle because it relies on rand() which may be bad, but ironically most (all?) the rng's that are in the standard library would be considered "bad" by modern standards.

[ska]

"bad" for what purpose? The linear congruent stuff and Mersenne twisters, for example, are leaps and bounds better than a typical rand() implementation, and very appropriate for many uses.

[gcp]

Sure, but we have generators now that are both faster and better, so there's no point in using the standard ones, aside for convenience.

[ska]

    aside for convenience.

You say that as if it is a small thing. Convenience, lack of additional code to maintain, consistency across platforms - for many projects these things will easily trump any algorithmic improvements from using something else.

[jackcviers3]

> keyboard bashing is a cheap price to pay for what you're getting back

Only if your program is trivial. That is, if you can afford to run it over and over with results you can verify in the output as being incorrect, sure, keyboard bashing works.

Most of us work on programs that have been made trivial by abstracting the complexity into a framework or protocol library - like a web server. You can keyboard bash out a correct rest implementation on top of a routing library in minutes.

The problem domain is tiny(but really flexible!), and largely automated by code generation in most languages. The programmer is only there to cross some t's and dot some i's.

It would be a waste of productivity to write your own http server from the ground up. Writing one is non -trivial. For every new programming language that wants to serve web apps, a webserver must be written in that language. Having a compiler that verifies or does more for you on a non-trivial program is great. Not saying c++ is the right language here, just that a statically compiled program with an expressive type system catches more errors at compile time. Some/(most) bugs are unapparent in localized, repeated runs and unit tests that really only ever test a small subset of the range of possible inputs.

I like easy as much as the next programmer, I just mourn the fact that we can't seem to provide a safe, simple and easy in the same programming language.

[gcp]

Other than out of bounds memory accesses and legacy code I feel there is not much that can go wrong.

If only we could stop at single-threaded applications :-)

I'm not convinced modern C++ stops all issues with pointers/iterators and ownership either. But it's hard to tell because every large-enough application inevitable has to interface with legacy pointer code.

[albinofrenchy]

The point about legacy pointer code is valid, but the benefit of the newer pointer / iterator / ownership stuff isn't really that it is in and of itself a magic bullet.

What it does do is make it easy to reason about how pointers are used across the application. Also worth noting that even with legacy libraries, you can wrap a given pointer with std::unique_ptr or std::shared_ptr and provide a custom deleter and maintain reasonable safety guarantees.

[gcp]

I do get it's easier. I use std::unique_ptr when interfacing with legacy code because I like that I need an explicit .release() to relinquish ownership. It's self-documenting.

But I was considering modern C++ compared to, for example Rust. I'm not sure if the memory safety issue that Rust solves still exists as strongly with a purely modern C++ codebase...but then again I never run into those either.

For threads it's no contest between Rust and C++, although TSAN is pretty damn nice.

[mempko]

Pointers are great! Without pointers, the web would not exist!

[zone411]

Your complaint about the slow compilation times might be addressed partially by Modules, expected for C++20. VS 2015 Update 1 and Clang already have experimental support.

[jcelerier]

in my experience when testing the current modules implementation, PCHs are still a good deal faster; if you use CMake they are dead easy to set-up so you may as well use them today.

[frozenport]

Modules help, but you're still trucked if you change an underlying header.

[rb808]

> I often have to modify headers that are included almost everywhere.

I think this problem started with templates - previously you wrote abstract base classes (interfaces) and concrete classes had most of the code changes. I avoided templates where possible largely because of this.

[jjaredsimpson]

nit: Aren't pointer arguments also pass by value? The data is the memory address not the underlying pointed-to object.

[duneroadrunner]

You can use the SaferCPlusPlus library[1] to get closer to "java safety".

C++ compile times are a problem. Apparently there is a C++ interpreter[2]. Anyone have any experience with it?

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://root.cern.ch/cling