On Fri, 31 Jan 2025 at 10:20, Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> 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.