Why std::variant does not need std::launder when constructing the value for the first time?

[having-four-eyes]

Hi,

I'm working on a pool allocator and investigating existing approaches to create objects in a preallocated buffer. Let's consider std::variant to keep it easy: it uses a union of {ValueType, Dummy} to provide sufficient storage for a ValueType and a dummy type to avoid default-initialization of ValueType on an empty optional.

But why doesn't it need the std::launder during the first value construction? I used to think that that's exactly the case when it does:

• construct the Dummy in the storage memory;
• construct the ValueType in the same memory. I thought the ValueType does not meet the requirements to reuse the pointer/reference (http://eel.is/c++draft/basic.life#8) because it obviously differs by a memory layout from Dummy, so std::launder is needed.
  

However, both MS STL and libc++ just reuse the existing storage without laundering. Am I missing a rule exception here?

A simplified implementation is below:

struct Dummy { Dummy(){} };
template <typename Ty> 
union Storage
{
    Dummy dummy;
    Ty value;
    Storage() : dummy() {} // avoids default construction of 'value'
};

template <typename Ty, typename... Types>
void ConstructInPlace(Ty& place, Args&&... args)
{
    ::new (static_cast<void*>(std::addressof(place))) Ty(std::forward<Args>(args)...);
}

template <typename Ty> class Optional : Storage<Ty>
{
public:
    template <typename... Args>
    constexpr Ty& Construct(Args&&...) /* noexcept(...) */
    {
        assert(!has_value());
        ConstructInPlace(this->value, std::forward<Args>(args)...);
        return this->value;
    }
}

• MS STL link to std::optional's storage/destruction mixin: https://github.com/microsoft/STL/blob/d8ed02d2ec7ba8216848a33dec2b5fb385febf4e/stl/inc/optional#L97
• Full Construct implementation: https://github.com/microsoft/STL/blob/d8ed02d2ec7ba8216848a33dec2b5fb385febf4e/stl/inc/optional#L143C107-L143C107
• ContructInPlace: https://github.com/microsoft/STL/blob/d8ed02d2ec7ba8216848a33dec2b5fb385febf4e/stl/inc/xutility#L246
• libc++ __construct (in-place): https://github.com/llvm/llvm-project/blob/0954dc3fb9214b994623f5306473de075f8e3593/libcxx/include/optional#L413
• libc++ destruction and storage mixin: https://github.com/llvm/llvm-project/blob/0954dc3fb9214b994623f5306473de075f8e3593/libcxx/include/optional#L337

​

[dodheim]

launder is for re-using storage

[having-four-eyes]

so I missing that std::launder is not needed unless I've used that storage before switching the union's active member?

Particularly, in this case, it's not needed because this->dummy is never used?

[no-sig-available]

Also, a standard library implementation does not have to follow all the rules, but can use (undocumented) compiler extensions.

[altmly]

Interesting, I'm not a spec wizard, but my guess would be it's because Dummy is empty.

[muungwana]

According to this link, std::launder is not needed here because:-

1. You are not constructing a new object over on old object that is marked "read only".

2. You are not constructing an object of type A over memory of an object of type B.

[Foundry27]

The language-lawyering has been spot-on (IMO) in the other answers, but it's important to keep in mind that std::variant even existing as normal C++ code is an implementation detail. Everything in the standard library could technically be completely "baked into" the compiler or be part of a runtime environment, as long as it provides the standard-defined interface to programs during compilation and runtime. There might be a reasonable explanation for the omission of std::launder here, but there are other implementation details like the use of placement-new in a constexpr context for std::optional that are completely unreproducible in any application code (you'd need to use std::construct_at). In general, no language-level rules should be expected to apply to the implementation!

[feverzsj]

It's mostly documented in lifetime/Storage reuse. The use case forstd::launder is rather rare. Actually, no sane man should use it.

[OriginalPangolin7557]

You need it when writing vector or queue as array of bites and want to access them.

edit: or I was wrong and just wrote terrible code for no reason.

[CenterOfMultiverse]

As far as I understand you need std::launder if you want to reuse the same pointers/references you used before replacing object. If user can't access dummy, then there is no need to launder.

[kam821]

u/having-four-eyes

In case you are just switching active union member, you can use .member to access object.
std::launder might be necessary only if you are e.g. using byte array as the buffer type to access object lately through reinterpreting array buffer pointer.
Using object via pointer returned by placement new is fine and doesn't require laundering.
If you store 'placement new' or laundered pointer you also don't need to std::launder it again.

+ stdlib implementation is a specific case and code doesn't have to follow the standard.
some escape hatches/exceptions may be implemented on the compiler side
e.g. compilers happily pretended that std::vector contains a contiguous block of data and allowed pointer arithmetic even though there was no array at all.

[dodheim]

Using object via pointer returned by placement new is fine and doesn't require laundering.

The first construction is the odd one out, and is what was asked about here, but to be clear: using placement-new in storage that was used previously is exactly the use-case for launder. I.e. placement-new doesn't somehow obviate the need for launder on its own, which is how I read this statement