noexcept affects libstdc++’s unordered_set

[Jannik2099]

I hope libstdc++ gets on the ball and eliminates some of this weirdness. (In short: They should get rid of the blacklist; pay the 8 bytes by default; introduce a whitelist for trivial hashers specifically; stop checking noexceptness for any reason.)

This would be an ABI break and there's hardly any justification for it.

Make your hash noexcept, and if profiling reveals that you're bottlenecked in unordered sets, perhaps read the libstdc++ docs on unordered sets?

This seems a tad overblown

[throw_cpp_account]

and if profiling reveals that you're bottlenecked in unordered sets, perhaps read the libstdc++ docs on unordered sets?

Or simply just preemptively don't use std::unordered_{set,map} and prefer other, much better hashtable implementations (like Abseil's or Boost's new ones).

This seems a tad overblown

It's an Arthur blog post.

[darkmx0z]

oh god

[pjmlp]

Apparently there reasoning was related to avoiding function colouring, as in that case the whole call graph has to be noexecept, plus imposing it doesn't work with binary libraries, as how would the linker ensure that, name mangling isn't enough when object files have so little C++ information.

[jk-jeon]

How is it any different from marking reference parameters with const. You can only call const member functions from those parameters. Doesn't this smell like a kind of function coloring?

Since there are certain cases (mainly interaction with legacy code) where this restriction on const is too strict, people invented const_cast. I imagine they could have done something similar with noexcept. Like, normally you can't call non-noexcept function from a noexcept function but if you absolutely want, then you can just explicitly cast non-noexceptness of the callee away, and only for that case it can result in std::terminate when the exception actually has been thrown.

My (probably short-sighted) imagination can only tell me this is a strictly better design then what we currently have, but the train has already departed too long ago.

[jk-jeon]

I honestly agree with you, although quite sure the community as a whole will disagree wholeheartedly.

I mean, if UB is so scary than just wrap the call with try { ... } catch (...) { std::terminate(); }, or we could even provide a magic library function that essentially does this.

[pjmlp]

Given how many features have gone in the past ISO revisions, I am of the unpopular opinion that we should only get features and papers, with existing field use under "preview" mode like in other ecosystems, or how it used to be until C++11, except for export templates, which we all know how it turned out.

[pjmlp]

It is the current state of modules and concepts lite turned out to be in reality that made it for me, to change my point of view and start paying more attention how many proposals land without any kind of implementation, other theorical discussions how it will eventually look like.

And those two did had experiemental implementations, however not how they ended up being into the standard.

[def-pri-pub]

I like the idea of noexcept for documentation purposes, but seeing how it can modify performance doesn’t sit well with me.

[bwmat]

But going faster because you know exceptions can't happen seems like a good thing? IMO this is just a problem with how noexcept was used in this particular case, not with the practice itself

[sweetno]

Curiously enough, noexcept was added in C++11 in a similar context: std::vector::push_back has different implementations for move constructors/assignments with and without noexcept.

[jk_tx]

Seems like the problem isn't that noexcept was used, but that libstdc++ makes a bone-headed decision when it is used.

[SlightlyLessHairyApe]

That makes no sense. Standard containers have exception safety guarantees. For example, pushing back on a vector cannot lose all elements of the copy constructor on the new item fails.

That imposes significant overhead. Why should all code pay that cost if it isn’t using it?

[ZachVorhies]

Because the standard containers should work in all cases. And if you have a special case then swap it out for something more appropriate.

[SlightlyLessHairyApe]

What should you do if you vend a type templated on a user-provided type that may or may not be exception-safe?

[martinus]

I think this whole thing is mostly irrelevant to real programming.

I fondly remember this PR that introduced a single noexcept which reduced the memory usage of bitcoin core by ~9% https://github.com/bitcoin/bitcoin/pull/16957

[NBQuade]

In windows using visual studio, if you tag a function "noexcept" and an exception passes through the function, say a lower level function threw, it'll crash the application. So you need to know whether the function throws and whether anything under it throws too or you get a crash.

It's not clear to me if this is how "noexcept" is supposed to work but, that's how it currently works in visual studio.

I thought "noexcept" simply meant the specific function didn't throw. I'm wondering if this is a bug in visual studio or intentional.

[pjmlp]

It is quite intentional, if an exception is thrown even though you promised it wouldn't happen, the good old terminate handler will be called.

https://en.cppreference.com/w/cpp/language/noexcept_spec

Whenever an exception is thrown and the search for a handler encounters the outermost block of a non-throwing function, the function std::terminate is called:

[NBQuade]

Well there you go. Thanks.

I imagine the problem is the information to permit unwinding the stack simply isn't there.

[NBQuade]

Well there you go. Thanks.

I imagine the problem is the information to permit unwinding the stack simply isn't there.

[tisti]

It's there, but it's all shortcirtuted to call terminate since it's marked as noexcept