On Fri, 31 Jan 2025 at 10:20, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi Jonathan,
>
>
>
> the value of the underlying bytes matter.
>

When do they matter? Only when trying to access them, right? The value
while in some temporary buffer (whether correctly aligned or not) doesn't
matter.


> Currently the C++ standard (AFAIK) does not specify, how pointers are
> represented in memory.
>
> There are only certain high-level guarantees, e.g.
>
>
>
> &p[i] = p + i
>
>
>
> or that increment/decrement can access the next/previous element.
>

Yes, I'm aware.


> Internally the small string optimization of the implementation(s) use the
> same pointer member variable for a heap pointer or for pointing to the SSO
> buffer.
>

Yes, I know, I wrote the code you're referring to.


> When relocating the object, this has to be tested, and the pointer value
> should only be changed, if it points to the internal buffer.
>

But you don't need to create a correctly aligned pointer into the buffer,
some sentinel value will work instead.


If we do not assume a certain underlying pointer representation, we cannot
> know, whether a pointer to std::byte and a pointer to char32_t has the same
> representation and we can just use the unaligned beginning of the buffer as
> marker, as we did in the original class.
>

Or use a null pointer to mean "points to the internal buffer" (because the
class has an invariant that its _M_data is never null) and copy the bytes
of (char32_t*)nullptr into the byte array instead. This is a problem that
can be solved by the author of tht basic_string implementation.
There's no need to know anything about the value representation of the
char32_t* pointer type.


> Probably the string class is an non-optimal example:
>
> Whoever creates the unaligned relocation should be the implementer of the
> standard library implementation or even the basic_string class itself, as
> private class internals are accessed and modified.
>

Yes. As I said: stop messing with std::lib internals, come up with a better
motivating example.



> They can just always use a byte-pointer anyway or make platform-dependent
> assumptions about the underlying representation
>

That's not necessary.


> It is possible to keep the char32_t pointer and use std::align to generate
> an internal aligned pointer without any assumptions about representation.
>
> So if one would bring up the example in the proposal, it should not put
> additional non-necessary demands into the language.
>

Indeed. A better motivating example is needed to demonstrate why the
proposal would be useful.


> Thomas/Frederick asked about making all pointer types the same size and
> representation (and probably set the representation) and make them some
> sort of 'intercompatible'.
>

Without defining what "intercompatible" actually means, as far as I can
tell. There's been a whole lot of back and forth about details of something
that isn't clearly stated in the first place. This all seems like a big
waste of time. Maybe some people in the thread are enjoying debating the
academic details, but it doesn't seem to be going anywhere.