On Thu, 30 Jan 2025 at 17:04, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> IMOH as internals are accessed, that code can only be done by the
> implementer's of basic_string or at least by the implementers of the
> standard library providing basic_string. Everything else is a hack.
>
>
> Thomas (Frederick) stated that the class is not used/called in its
> unaligned state, so using the 4 bytes of the pointer creatively (either as
> unaligned byte pointer representation even for char32_t or as I suggested
> letting it point to the first aligned byte within the SSO buffer) probably
> has to be done, even if it is violating the class invariant, as long as the
> class variant is correctly restored, when unpacking to aligned memory.
>

If the object isn't accessed while in unaligned memory, why does the value
of the underlying bytes of that pointer matter in the slightest? They're
just bytes, not a pointer value, aren't they?


>
>
> I understood the example more like a typical user class, which has to cope
> with unaligned storage.
>

Unless the type is trivially copyable, you cannot use memcpy to copy the
underlying bytes to an array of bytes and then back in again. That
certainly applies to a typical user class.

The motivation seems to be to allow such copies of the underlying bytes,
but without actually touching the relevant rule (which is in
[basic.types.general]). So the motivation is lacking.



>
>
> But perhaps I understood the OP wrongly.
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jonathan Wakely <cxx_at_[hidden]>
>
> On Thu, 30 Jan 2025 at 10:10, Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> If p is pointing to buf,
>
> set it to the first aligned byte of buf in the unaligned memory.
>
>
> That would break invariants of the libstdc++ basic_string, which uses `p
> == buf` to detect when the string is no heap allocated. If you point p to
> the middle of bug then the destructor will do deallocate(p, capacity()+1)
> which will try to delete non-allocated memory.
>
>
> The solution is: stop trying to mess with the internals of std::string.
> Come up with a better motivating example.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>