https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112591
Halalaluyafail3 <luigighiron at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |luigighiron at gmail dot com
--- Comment #5 from Halalaluyafail3 <luigighiron at gmail dot com> ---
(In reply to Tomasz Kamiński from comment #4)
> The standard wording seem to explicitly allow this two Empty object to have
> same address. Firstly [variant.variant.general] p1
> (https://eel.is/c++draft/variant#variant.general-1) explicitly states that
> object alternatives are nested within the variant object:
> > When an instance of variant holds a value of alternative type T, it means
> > that a value of type T, referred to as the variant object's contained
> > value, is nested within ([intro.object]) the variant object.
>
> And the core language gives carve-out in [intro.object] p10
> (https://eel.is/c++draft/intro.object#10) for nested-within objects to have
> same address:
> > Two objects with overlapping lifetimes that are not bit-fields may have the
> > same address if:
> > (10.1) one is nested within the other
>
> So &std::get<Empty>(v.e) may have same address as v.e, and that may have
> same address as v.
&std::get<Empty>(v.e), v.e, and v can all share the same address because of the
nesting, yes. However, neither &std::get<Empty>(v.e) nor the base class Empty
can share the same address since neither is nested in the other. The members of
a class are not nested within the base classes of the same class, nor vice
versa. That's why for example with
struct A{};
struct B:A{A a;};
GCC will make B 2 bytes and store the two A objects separately. The issue is
that because std::variant uses a byte buffer pre-C++17 it can't see an A object
will be created so it doesn't know to store it separately.
