C++17 Is Now Official

[pal666]

Here's why, it's not a committee, it's an ever-expanding mob:

in real world, outside of your inflamed brain, complex tasks require many people and many man-hours
large number of committee participants in recent years is a good sign of healthy c++ state and rapid development

[Kemosabe]

I propose that for the 2020 revision, we add an standard error message "Index was out of range" to be used for all runtime errors, send the committee members retirement gold watches, ban any further C++ standards work for the next 40 years (by which time I expect to be dead or at least retired), and finally we change the name of the language to "Visual Basic".

Because they seem to want to turn it into just such a monstrosity.

Actually this doesn't really resemble the truth. What is speaking here is you feeling overwhelmed by the options C++ offers. But this is fine. You can accept it. And in fact, C++ is underspecified. There are some blind spots and this is why you will observe different behaviour when compiled with different compilers under certain circumstances. And no - this is not a real big deal in most scenarios ;-)

[MartinN]

curious - not to knock Rust or anything, but how possible is it to write safe 'rust-like' C++ code with the newer C++ standards? I'm still kind os stuck between C++98 and C++03... and then Java mostly after that.

[mmstick]

curious - not to knock Rust or anything, but how possible is it to write safe 'rust-like' C++ code with the newer C++ standards? I'm still kind os stuck between C++98 and C++03... and then Java mostly after that.

Honestly? Not at all. C++ picks up a few features that are similar but inferior to what Rust offers by default, but it does not alter the language in a way that makes it possible to write safe C++ software. Maybe slightly safer C++ software, if you can convince both your team and all of your dependencies to rewrite everything using the safer features, but nowhere near the level of safety of Rust.

Rust employs a borrowing and ownership mechanic that's empowered by lifetime annotations, in addition to traits like Send & Sync for ensuring safety across thread boundaries, and that's something that C++ would have to offer at the core language layer in a very backward-incompatible way.

[Delgarde]

curious - not to knock Rust or anything, but how possible is it to write safe 'rust-like' C++ code with the newer C++ standards? I'm still kind os stuck between C++98 and C++03... and then Java mostly after that.

The difference is this – in Rust, safe code is the default, due to various language constructs... it's not difficult to write unsafe code, but it's obvious when you're doing so because all the unsafe code is, by definition, in unsafe{...} code blocks. And some of those constructs do make it somewhat difficult to learn... but they do help eliminate wide categories of coding error.

In C++, the opposite is true – it's not impossible to write safe code, but you have to know exactly what you're doing. The original C++ was decidedly unsafe – newer versions of the language spec introduce various new features that can help, but they don't make it any harder to be unsafe, and by constantly adding to the spec, it becomes very difficult for an inexperienced developer to understand what's safe and what isn't.

To go with the usual analogy of shooting yourself in the foot with programming languages – Rust makes it difficult to accidentally shoot yourself, because by the time you've figured out the safety catch, you've been forced to learn proper gun safety. By contrast, the C++ gun has no actual safety catch, and relies on developers figuring out the best practices that allow them to avoid injury... this works about as well as you'd expect.

[Hi-Angel]

How timely — I am already using C++17 features like std::variant and std:ptional for writing a pidgin plugin, and didn't even know C++17 wasn't actually released. To be honest when I started using std::variant, I didn't even know it appeared only since C++17 — like, geez, this is so obvious feature, how could it take them so long?

[RealNC]

To continue the analogy of safety and guns, C++ is more like a big box where you can find gunpowder, explosives, fuel (for rockets and missiles) in it, alongside another box with gears, switches, pins, rings, springs, etc, to build safety switches from.

If you're not good at building safety switches, you're going to blow something up unintentionally :-)

I think the bottom line is simply that C++ is just not a "productivity language" for people who are not experienced developers. It can be used as a productivity language by people who are, however. They make the biggest explosions, too!

[Delgarde]

I think the bottom line is simply that C++ is just not a "productivity language" for people who are not experienced developers.

And becoming an experienced developer involves making mistakes and learning from them. That's true of any language, but C++ is a relatively unforgiving language to make mistakes in.

[kpedersen]

When I look around for libraries, if I see one that says it uses, boost, asio or C++ >= 11, I simply discard it and continue my search.
Basically "modern" C++ is too awkward to port to multiple platforms and it is too complex to rip out the stupid parts.
It also loves to do terrible async related designs which are simply not valid when adding to existing architectures.

It is a shame because I still see C++ as the only valid choice of language when starting a new project. I just wish the next standard would focus on safety rather than feature creep.
For example, it is ridiculous that iterators are so unsafe compared to std::vector::at(size_t) and yet required for accessing much of the STL.
Smart pointers are a good step but still not quite there, for example if code within a member function indirectly wipes the last reference count to "this", then everything you do is basically on a dangling pointer to this. The std::weak_ptr<T>::lock() is close, but not quite there yet.

[discordian]

curious - not to knock Rust or anything, but how possible is it to write safe 'rust-like' C++ code with the newer C++ standards? I'm still kind os stuck between C++98 and C++03... and then Java mostly after that.

Yes, it is possibly since C+11 (move-semantics + owning smart pointers, thread synchronization), but this is often a question about all the existing code which you usually have to depend on. And unfortunately old habits die hard and C++11 is more of less unsafe by default, so you would need some easy rules and a way of enforcing them - we are not there yet.
When you got the time, I would recommend you to watch "leak freedom in C++ by default" by Herb Sutter.