Details
-
Epic
-
Resolution: Invalid
-
P2: Important
-
None
-
None
-
None
-
std::launder
Description
According to resident language lawyer villevoutilainen_qt, with C++20, the only remaining use case of std::launder() is as a de-virtualization barrier:
class B { ~~~~ }; class D1 : public B { ~~~~ }; class D2 : public B { ~~~~ }; static_assert(sizeof(D1) == sizeof(D2)); void mutate(B *b) // out-of-line, so compiler doesn't see what's going on { assert(dynamic_cast<D1*>(b) || dynamic_cast<D2*>(b)); b->~B(); new (b) D2(); } D1 d; B *b = &d; b->someVirtualCall(); mutate(b); b->someVirtualCall(); // compiler may assume vtbl didn't change and call D1::someVirtualCall() directly std::launder(b)->someVirtualCall(); // OK, compiler musn't de-virtualize
As for const and reference members (the C++17 case), there was only one compiler (IBM xlc++) which optimized on this, but only for static-storage duration objects. So adding it to Q_APPLICATION_STATIC was ok, as a precaution. Everything else is not needed, esp. as the aforementioned compiler became non-compliant in C++20.