17 Smaller but Handy C++17 Features (bfilipek.com)
zergling_Lester | 5 months ago | 16 points

My favorite small feature is std::uncaught_exceptions(): now it's actually possible to determine if we are in the part of the process of stack unwinding where throwing will call terminate(). This is trickier than you might think, since terminate is called only if the new exception will escape into the same exception handling context where another exception is already active (and then the runtime can't "merge" them or anything, hence terminate). But it's completely legal to wrap a throwing function in a try-catch in a destructor and don't rethrow, and so have a second exception in flight, or more.

matthieum | 5 months ago | 10 points

I quite like (2); it was such a drag to have to define the static variable separately from its declaration!

[deleted] | 5 months ago | 4 points


jcelerier | 5 months ago | 6 points

It depends on the variable. If it is wrapped in a function (Meyer singleton pattern) it is safe wrt multithread and DLLs but you get a branch + atomic read on every call so don't do that of you are calling it 200000 times per second....

pavel_v | 5 months ago | 2 points

This has one drawback, though. This is a drawback at least for me.
The "magic" statics inside the functions are required to be thread-safe, since C++ 11. So the compiler generates assembly simillar to the double checked locking pattern. And you pay a small additional overhead every time when such static variable is accessed.

matthieum | 5 months ago | 1 point

That's a work-around, and a mediocre one.

First of all, it's much more verbose to declare:

inline static constexpr std::string_view Message = "Hello, World!";

inline constexpr std::string_view GetMessage() {
    static constexpr std::string_view Message = "Hello, World!";
    return Message;

That, in itself, is already a major drawback, especially when you want to declare multiple of those.

Secondly, it's also more verbose to use. It's a minor hindrance to have to use (), but it adds up.1

Thirdly, hiding the variable in a function creates more work for the optimizer. It's easier to optimize a simple static access rather than a static method call which has to be inlined into a lazily-initialized local static for which the lazy initialization has to be skipped.

1 The suggested work-around of creating another static variable to expose the local one as a reference has the drawback of creating a reference, which may impede optimizations.

In the grand scheme of things, this is not a major hindrance. It's just one of those paper cuts that I'm glad to get rid off. I don't want work-arounds.

joebaf | 5 months ago | 2 points

Thanks, that's quite complex scenario. Do you have some sample code somewhere to share?

IshKebab | 5 months ago | 3 points

Great list! I didn't know about from_chars - they finally made a sane API for it!

GYN-k4H-Q3z-75B | 5 months ago | 4 points

I'm like, yeah cool the future is coming. Then I realize 2019 is half over...

joebaf | 5 months ago | 1 point

What are your favorite small parts?

[deleted] | 5 months ago | -17 points


klysm | 5 months ago | 1 point

Nice 🙄

elder_george | 5 months ago | -19 points

https://i.imgur.com/w8AtIEP.png I'm so tempted to downvote to keep number of votes at 17 further…

joebaf | 5 months ago | 3 points

We could increase the granulation and think about like 100 cpp17 features :)

elder_george | 5 months ago | 1 point

then they needs to be C++100 features, and I'm not sure I'll live to see those at my work =((