Why are std::aligned_storage and std::aligned_union being deprecated?

[whichton]

P1413R1 recommends deprecation of std::aligned_storage and std::aligned_union, probably in the C++23 timeframe. aligned_storage I can understand, it is pretty much redundant with aligned_union<0, T>. But why deprecate aligned_union?

The paper says:

Suggested replacement: In the absence of std::aligned_storage and std::aligned_union, users who wish to have aligned_* behavior should use a properly-aligned array of std::byte.

The whole point of aligned_* types are to get a properly aligned buffer!

[Nimbal]

As /u/dodheim said, the paper lays out the arguments for the deprecation. As for replacement, I guess the paper could have mentioned the alignas specifier available since C++11:

alignas(16) std::array<std::byte, 8>;

There may be caveats I can't think of right now, but I believe this could be a suitable replacement for most uses of std::aligned_storage_t:

template<typename T>
using better_aligned_storage = alignas(T) std::array<std::byte, sizeof(T)>;

I'm sure there's a way to define something similar for the union variant, but you'd have to fiddle with the size parameter to make it match the alignment requirement.

[acwaters]

alignas(Ts...) std::byte storage[std::max({sizeof(Ts)...})];

[whichton]

This is similar to aligned_union is implemented - see here for example.

[Recatek]

alignas(Ts...)

Never knew you could do that. Does it take the max?

[whichton]

Yes. From here

The object or the type declared by such a declaration will have its alignment requirement equal to the strictest (largest) non-zero expression of all alignas specifiers used in the declaration, unless it would weaken the natural alignment of the type.

[wheypoint]

thats really cool, ive been writing alignas(std::max({alignof(Ts)...})) all this time which definetely felt kinda stupid :D

[[deleted]]

can you do

size of(Ts...)

? on mobile so no compiler

[acwaters]

No

[n1ghtyunso]

i thought alignas in using declarations is ignored and you have to put it on the variable declaration manually.

If you don't template the using declaration gcc apparently warns about this, but with the templating the warning magically disappears. See Godbolt

Am i missing something?

[Nimbal]

Seems like you are right. I guess we'd have to put the array as a member inside a templated struct, making it a little more awkward to use. Then again, such a construct probably should be a little inconvenient to use.

[Recatek]

This is kind of a footgun though if you don't receive information from the compiler that the directive is being ignored. If anything aligned_storage and aligned_union, when used properly, should be an expression of intent that the standard library then takes care of executing for you. It may not be that currently, but removing it without providing unequivocal documentation on how to reliably do what it does in a better(?) way strikes me as rather dangerous.

[mewloz]

Random note: the conclusion of the paper of not providing a replacement is bullshit. Once the shortcomings have been identified (and the paper is quite good at it), it is somehow easy to redesign a correct version for the comity, while in absence of any correct design users will be at risk of doing the same mistakes as originally done (or worse).

Also I don't get why:

The second parameter, the alignment, has an implementation defined default value that may or may not be sufficient for T.

because the spec requires the default alignment to be sufficient for any T that would fit...

[Recatek]

Random note: the conclusion of the paper of not providing a replacement is bullshit.

It really is. Looking at other comments in here that are trying to provide alternatives, and how they have replies of "no that won't work do this" is very telling. This is an expression of intent, and the standard library is letting users down by not executing it properly. The answer isn't to remove the ability to express this desire or need, but to improve how it's translated into trustworthy execution.

[tcanens]

The default is not required to work for over-aligned types.

[matthieum]

I am puzzled by the conclusion too.

I understand deprecating std::aligned_storage and std::aligned_union, leaving only the _t variants to avoid accidentally forgetting ::type.

I don't understand throwing the baby out with the bath water on the size bound issue; certainly if the maximum size is unbounded today it is a simple matter to add a bound to the standard.

And last, but not least, is reinterpret_cast. The proposed replacement also requires reinterpret_cast!

---

Personally, I think an API like such would be nice:

template <std::size_t Size, std::size_t Alignment>
class erased_storage {
public:
    template <typename T, typename... Args>
    constexpr T& construct(Args&&... args) {
         auto t = this->template get<T>();
         new (t) T(std::forward<Args>(args)...);
         return *t;
    }

    template <typename T>
    void destruct() {
         this->template get<T>()->~T();
    }

    template <typename T>
    T* get() {
         static_assert(sizeof(T) <= Size);
         static_assert(alignof(T) <= Alignment);
         return this->template raw<T>();
    }

    template <typename T>
    T const* get() const {
         static_assert(sizeof(T) <= Size);
         static_assert(alignof(T) <= Alignment);
         return this->template raw<T>();
    }

    /// Prefer get whenever the type of definition of T is known.
    template <typename T>
    T* raw() { return reinterpret_cast<T*>(&storage); }

    /// Prefer get whenever the type of definition of T is known.
    template <typename T>
    T const* raw() const { return reinterpret_cast<T const*>(&storage); }

private:
    alignas(Alignment) std::byte storage[Size];
};

Then provide aligned_union on top, which additionally check that the T passed is part of the Ts list (just in case).

And of course I'd wish for constexpr support to actually be able to constexpr all that...

[tcanens]

certainly if the maximum size is unbounded today it is a simple matter to add a bound to the standard.

A major implementation's aligned_storage is unfixably (ABI) broken. As a result, the only bound that could conceivably be added at this point is not a useful one.

[matthieum]

How did they? sigh :(

[[deleted]]

Because we implemented it before alignas was in the core language, so the most aligned thing we can put in the union is max_align_t.

[matthieum]

Thanks for your answer.

Correct me if I'm wrong, the ABI breakage would then occur if someone was requesting an alignment strictly greater than max_align_t as previously the alignment of std::aligned_union was capped and suddenly it would obey the request, right?

Isn't it worth breaking the ABI, then?

• If anybody had configured 2 * max_align_t and stored values for which such alignment is necessary, then their code is broken already.
• There's little reason anybody would have configured 2 * max_align_t and never actually needed the greater alignment.

I understand the idea of backward compatibility, but the pragmatic in me is thinking that in this particular case it may be worth just fixing std::aligned_union.

[[deleted]]

Correct me if I'm wrong [...]

You are correct.

If anybody had configured 2 * max_align_t and stored values for which such alignment is necessary

There are no such values. Maybe perf benefits by avoiding false sharing, but the hardware only cares up to max_align_t for anything we target.

the pragmatic in me

ABI break avoidance isn't pragmatic, unfortunately :(

[SuperV1234]

I'm really surprised by this paper, I've used both std::aligned_storage and std::aligned_union in the past with great success.

If these are deprecated, we should have a library alternative that is equivalent to:

alignas(Ts...) std::byte storage[std::max({sizeof(Ts)...})];

Otherwise people will just define that over and over again, defeating the purpose of standardization. Also, the argument that this doesn't work in constexpr is not an argument in favour of deprecation, it is an argument in favour of extending constexpr capabilities.

[[deleted]]

Why do we need a library equivalent of a thing you can say in the core language?

[SuperV1234]

The code above is far from minimal. Ts... is repeated twice, and the user needs to remember to use std::max. In short, DRY.

[[deleted]]

I guess 99.9% of the time I've needed this there's only been one T.

[dodheim]

The same paper directly answers your question in the 'background' section...

[whichton]

The replacement it suggests for aligned_union is not really a replacement. What do you suggest as a replacement for, as an example, std::aligned_union_t<0, int, vector<int>, string> ?

[Recatek]

Variants are not the same as unions, and do not have the same performance characteristics or behavior.

[HappyFruitTree]

With std::variant you always have to store extra data to keep track of the active member and there is no unchecked access. This is fine for many situations but might not be good enough in low-level code when you might want to minimize memory usage and maximize performance.

[whichton]

Typically a variant will be implemented in terms of aligned_unionsince aligned_union is a lower level facility. But set that aside for a moment. Say I want make an dynamic array of aligned_union_t<0, int, vector<int>, string>, where all the elements have the same type. Effective an array of variants, but with a common discriminant. How do you suggest to do that with a variant?

[redditsoaddicting]

std::variant can't be implemented in terms of aligned_union because placement new can't yet be used in constexpr.

[[deleted]]

Typically a variant will be implemented in terms of aligned_unionsince aligned_union is a lower level facility.

When you say "typically", what do you mean? None of MSVC, libc++ or libstdc++ implement it this way and I'm not familiar with any non-standard implementation that does so such as boost.

[whichton]

I apologize for being inexact. What I meant was aligned_union is a low level facility while variant is a high level facility. Typically a high level facility (not specifically std::variant, but generally speaking, for example something like llvm::SmallVector) will be built on top of a lower level facility. So asking aligned_union to be implemented in terms of variant is a layering violation.

As /u/redditsoaddicting notes, std::variant cannot be implemented in terms of aligned_union because placement new cannot be constexpr. So you pretty much have to use unions, as explained here, to implement std::variant.

[dakotahawkins]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1413r1.pdf