No, it can't. You have the same guarantee of layout for string as well. The
only time that you don't have those guarantees (afaik) are when you mix
visibility of member variables (the guarantee holds per visibility) or when
you are using virtual inheritance ( i.e like class foo : virtual bar {...};
). Multi inheritance has some implementation-defined layout but the members
between bases should also be ordered according to the order of inheritance.

// Robin

On Wed, Jun 18, 2025, 09:25 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> So it could be that an imaginary C++ implementation randomizes the order
> of members in non-standard layout types per type for security reasons?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 18.06.2025 07:50
> *Betreff:* Re: [std-proposals] I have a span but I need a container
> *An:* std-proposals_at_[hidden];
> *CC:* Jason McKesson <jmckesson_at_[hidden]>;
> On Wed, Jun 18, 2025 at 12:57 AM Simon Schröder via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > There is one thing that the standard guarantees which is why in most (or
> even all) implementations this trick currently works: If member variables
> are defined in the same order in two different structs they are layout
> compatible. This is something that C specifies right from the beginning and
> C++ has taken over. It is why including a header in multiple translation
> units actually works. So, there is a guarantee for the layout.
>
> Note that this is only true for standard layout types... which
> `std::string` is not.
>
> No, the reason why this "works" is that implementations need to give
> subobjects *some* particular layout within a higher level object.
> Because that layout must be consistent across all uses of that type
> within that implementation, if you know what an object's layout is for
> your implementation, you can build something which mimics that layout.
>
> But it only works for that implementation. And it requires knowing
> very specific implementation details about an object which you are not
> generally privy to.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>