On 2/18/22 13:33, Mikhail Kremniov via Boost wrote:
Hi,
Initially, I posted this question to the boost-users list, but then I was advised to repost it here.
I wonder, what is the Boost community's opinion of std::launder? In particular, of its necessity when accessing an object that was created via placement-new in an aligned_storage. As I can see, it's used by Boost.Beast in its implementation of the variant type, but not in other parts of Boost. The reason I'm asking this is that I'm working on a C++14 code-base that uses Boost.Variant and Boost.Optional extensively (as well as other parts of Boost that use Variant and Optional internally). Now we're trying to switch to C++17 at least, and I worry whether it could potentially break things.
To put things into context, C++ standard states in the [basic.life] section that if you had an object and then created a new one in the same location, you can use the pointer to the old object to refer to the new one only if (among other things) "the new object is of the same type as the original object (ignoring the top-level cv-qualifiers)".
This means, as I understand it, that it's technically illegal to reinterpret_cast the pointer to aligned_storage to the pointer to the actual type of the object created via placement-new, because placement-new has already ended the lifetime of the aligned_storage object. So, implementations of Boost.Optional and Boost.Variant are illegal then (?). But it's been like that since C++03 and Boost worked fine all that time, so it looks like this UB existed only "on paper".
Casting a pointer is not illegal. Accessing the pointed object is, if the object does not actually exist at the pointed location. That is, if at the aligned_storage location an object of type T was constructed (through any means described by the standard), you can cast the pointer to aligned_storage to a pointer to T and dereference it, and this is ok. If such an object does not exist, then dereferencing the pointer is UB.
But C++17 then added "Note: If these conditions are not met, a pointer to the new object can be obtained from a pointer that represents the address of its storage by calling std::launder". So now the language has the ability to deal with that UB, and a question arises, is it possible that compilers could start to use the UB to perform additional optimizations and make it a real UB? Also, I've seen a couple of times on stackoverflow.com people saying that it's actually fine to reinterpret_cast the storage in C++14, but in C++17 it's not (they didn't explain why though).
What std::launder is intended to be is a fence for compiler speculations as to the possible value in the dereferenced location. That is, in the following example: alignas(int) unsigned char storage[sizeof(int)]; int* p1 = new (storage) int(1); float* p2 = new (storage) float(2.0f); int* p3 = new (storage) int(3); std::printf("%d\n", *p1); the program is allowed to print 1 because the compiler may speculate that this code does not modify the value pointed to by p1. Adding this line immediately before printf: p1 = std::launder(p1); ensures that the compiler "forgets" whatever assumptions it had about the value pointed to by p1, so printf has to reload the value (or, at least, the compiler has to re-evaluate its assumptions given that the value could have been modified through other means). Note that p3 in this example is guaranteed to point to the int of 3 regardless of the launder. Given the above, I don't think Boost.Optional or Boost.Variant are affected. For both of these components, pointers and references to the stored value are invalidated if the value is destroyed (e.g. by resetting boost::optional or changing the current value type of boost::variant). It is also illegal (or simply not possible) to obtain a pointer or reference to the value that doesn't exist in the internal storage. boost::optional<int> opt; opt = 1; int* p1 = &*opt; opt = boost::none; // makes p1 invalid opt = 2; // p1 is still invalid p1 = &*opt; // now p1 points to 2 std::launder may be useful to the users of these components, if one keeps around a pointer to the stored object without re-obtaining it from boost::optional or boost::variant. But frankly, I don't see the point, as obtaining the pointer is a trivial and logical thing to do anyway.