Pick a C++ version and use that then. Compilers are not dropping old versions of the std, but the new versions are just that new. No deprecation affects an older version of C++ and no one is forcing developers(as seen by the 20-30% that still use C++98/03) to upgrade their code bases.

Yes, all you need to do, with both g++ and clang, is to specify the version of the standard that you want. Picking a mature standard makes it likely that most bugs have been fixed.

Compiler writers are pretty quick to add support for new features--I'd say it's about a year-ish between being added to the standard (which is not the same as the actual release it's in!) and actually being usable in a compiler.

Where the delay comes into play is that most projects require a minimum support of a compiler that's several years out of date. And if you're required to support 4-year-old compilers, then C++17 features aren't going to be available, despite them being available in the newest versions of all compilers. Back in 2018, I was working on a project where I gave up and used C++17 features (constexpr if) because I knew I could get away with only supporting a Clang that's a few weeks old.

Compiler writers aren’t that far behind? C++17 is mostly supported. C++20 is one year old!

"C++20 is one year old!"

The ISO standard was published in December of last year. So, technically, C++20 is only four months old.

> C++17 is mostly supported.

For essentially any other language this would be an absurd thing to say. For those languages you wouldn't consider a feature added until it was supported by the reference compiler

If you are using GCC, Clang, or MSVC then the standards support is excellent[1].

But putting that aside

> For those languages you wouldn't consider a feature added until it was supported by the reference compiler

Well, there is no reference compiler for C++. I don't think any language with either an ISO or ECMA standard has a reference compiler or interpreter.

There are gaps in support here in and there. But I would still say those mainstream compilers "support" C++17 for the same reason I would say that Chrome "supports" CSS3, despite it not implementing the full specification.

[1] https://en.cppreference.com/w/cpp/compiler_support

Only for languages that lack multiple implementations.

Some of the additions, like coroutine support, are roughly bug fixes.

Nope, Python 3 showed what happens.

What happens? You become the most-widely used language on the planet? The Python 2-3 wars are over. Python 3 won.

I just installed Python 2.7 on my new project because some critical libraries used by the customer don't care Python 3 exists.

Open source ones?

To some extent yes, and no I am not going to mention which ones.

I just can't think of a major open source python lib that hasn't added support for 3 if the functionality wasn't replaced by a new feature in 3.

Github is a tiny drop on the universe from enteprise computing.

You get 10 years of headaches for everyone who gets close to the language. Even today, the python executable in Ubuntu is called `python3`, not `python`.

To be fair though, it would be less of a problem for C++ than it was for Python, since you wouldn't have to depend on the compiler from the end-user system.

backwards compatibility is a bitch.

But yes, there's a reason why high-visibility C++ projects like Chrome basically white-list 30% of the language and keep it that way, to some small sub-set they feel is "good enough".

The problem is the fragmentation this causes. I pick these 5 features of the language, you pick another 7, I can't use your lib, etc, etc.

C++ is becoming extremely bloated. Bjarne said as much in one of his recent criticisms at the highly-specialized use-case proposals that people wanted to make "standard".

I enjoyed his C++11 book but now that's probably all outdated "oh we don't do it that way anymore" stuff and I can't afford to just buy 2-3 1000-page books every year to keep up. Got better things to do.

Sadly, I really doubt it. The standards committee seems mostly interested in adding new template metaprogramming features at this point. What I /really/ wish they would focus on is modules. 100% of C++ developers suffer from horrible compile times, and yet it seems to always get punted.

(Not to mention that forcing developers to write header-only libraries to use templates pretty much makes them way less attractive anyway)

Edit: maybe I'm wrong? It looks like modules are in C++ 20. No idea if any compilers are supporting them yet.

Modules doesn’t even really speed up the build if you have a highly parallel build... and it’s unclear how build tools should support it in a uniform way. I think modules will go unused but I hope I’m wrong

Modules have been released with C++20, but no compiler has a complete implementation for them yet. Also the standard library hasn't been modularized yet.

How is it possible that modules were released, if nobody has a working implementation? I was under the impression that proposals needed at least a proof-of-concept implementation from a sponsor. My exposure to this is searching the CMake tracker for this last year and seeing that it wasn't even working there yet.

> How is it possible that modules were released, if nobody has a working implementation?

there were plenty of experimental implementations over the years, some people have been using some flavour of "modules" with MSVC and Clang for something like 5 years... hell, technically it has always been possible to compile code as objective-C++ to leverage the objc module system if you could afford to use clang everywhere

As the other answer said, nobody has (yet) an implementation of the _released_ standard, but both GCC and especially Clang have had modules very close to what stabilized by C++20 for years. You can enable them by specifying a flag (-fmodules-ts) on any recent release of Clang.

I know that but I'm just baffled that the text of the standard could be released at a point in time when nobody has succeeded at implementing it fully. That seems like it would almost guarantee that no one implements the standard as it's written, as there is no proof-of-concept that it's truly viable... I'd expect to see several revisions to this before C++23 as the compilers work out the issues.

MSVC is expected to have C++20 feature completeness in VS 2019 16.10 Preview 3.

https://github.com/microsoft/STL/wiki/Changelog#expected-in-...

Watch the Visual C++ virtual day coming next week.

The standardization work for modules is done. Now all build tools and code bases need to start supporting it in a good way.

Isn't modules already a part of C++20?

There is. It's called Zig[1]. Usually I would have written Rust, but it's good to give Zig more publicity.

[1] https://ziglang.org/

This evangelism stuff has really got out of hand on HN - a whole new language is literally the opposite of what the parent asked for. To make matters worse, the languages you choose to evangelize are new/experimental, making your comment even less on point.

Yeah. I like rust but I feel like its pushed way too hard. If its really 'that good', people will slowly pick it up.

I personally don't like c++, but I wouldn't enjoy someone going on a rust thread and shilling c++. So I won't shill rust on a c++ thread. Seems similar for Zig.

As a huge fan of Rust, I am very interested in people writing comments about what C++ does for them that I'm missing in Rust.

I want more C++ shilling in Rust threads, and I don't think I'm alone.

Please, give me detailed examples of how you can use SFINAE or whatever to express useful misuse-resistant abstractions that can't be expressed with Rust's feature set. Please tell me about classes of bugs you can prevent in C++ that can't be similarly prevented in Rust.

Or maybe C++ isn't safer, but it's more performant? Easier to use? Easier to learn? Easier to troubleshoot and debug?

I agree that the Zig comment that started this sub-thread didn't contribute to the conversation. If we disagree, although I'm not sure we do, it's in that I'd rather call for higher-effort comments about the benefits of other languages instead of fewer comments about them.

- GPGPU programing ecosystem like CUDA and SYSCL (note eco-system, not just a compiler that generates PTX code)

- Game engines like Unreal and Unity

- GUI frameworks like wxWidgets, Qt, MFC, WinUI

- Being the language of choice to contribute anything to GCC or LLVM

- Being the language of choice for the native libraries ecosystem and runtime extensions to plug into Java, .NET, nodejs.

- Being the language to write drivers in macOS (IO Kit/Driver Kit), and Android alongside Java (Project Treble)

- Being avaialble out of the box on macOS, iOS, Windows, Android, Playstation, XBox, Switch SDKs and respective IDE tooling

So you can decide to deal with some of C++ flaws, and enjoy 40 years of history, or spend part of your application development budget into building a Rust ecosytem.

> Windows

The C++ SDK is definitely not available out of the box on Windows. You have to install it (and update it manually!).

Only for those that chose the path of not using the OS vendor tools and don't install Visual Studio.

Not only it is automatically selected in the respective workloads that depend on it being avaiable, it gets updated.

Eigen, although often criticized for its long build times, is still the only linear algebra library that can lazy-evaluate and optimize expressions in compile-time, thanks to C++’s template metaprogramming.

In overall Rust’s current type system isn’t good enough to match what C++ has for numeric computations, although there have been some recent improvements such as the min-const-generics feature. I’ll probably try the language again once const generics are finished.

> If its really 'that good', people will slowly pick it up.

Empirically, that's been happening?

It's just shilling.

OP asked for:

> only fixed bugs or deprecated old features

When you get right down to that, you do end up with something like Rust. E.g. C++'s move semantics are weird because for historical reasons copying is the default. Get rid of those historical reasons, and there's no reason not to do it the Rust way.

40 years of "no big breaking changes" really is a lot of cruft.

> and there's no reason not to do it the Rust way

memcpy everywhere is definitely not the best answer to every problem

If you want a copy constructor, it would work like this:

Copy : Clone :: Move : Relocate

I.e. there would not be the presumption that everything is automatically movable or coppiable, there would be magic traits to indicate memmove / memcpy and friends, and then plain old stdlib super traits for user-defined cloning and relocating.

This is the the right design for move constructors, full stop.

It's not like C++'s move semantics magically get rid of the necessity of copying data either.

I meant to write it's not just shilling.

OP didn't ask for a new language that is stable, they asked for a stable C++.

But yes, it's true that Zig aims to be a minimal, stable language - when they go to 1.0, which hasn't happened yet. It's still changing frequently.