In my reading the pointer value itself can become invalid, the pointer doesn't need to change value.
The value of a trivially copyable type is determined from its value representation. The value representation can only change when the object is accessed. But a pointer can become invalid without accessing it, therefore it's the value itself that has to become invalid in that case.
From: "language.lawyer--- via Std-Discussion" <firstname.lastname@example.org>
Sent: June 23, 2021 8:40:18 AM GMT+01:00
To: Bo Persson via Std-Discussion <email@example.com>
Subject: Re: [std-discussion] On "transparently replaceable" in std::vector operations
On 23/06/2021 10:06, Bo Persson via Std-Discussion wrote:
On 2021-06-23 at 08:35, language.lawyer--- via Std-Discussion wrote:I'm asking about C++ abstract machine behavior, not about how it may be implemented.
On 29/04/2021 17:08, Jason Cobb via Std-Discussion wrote:No, there is no need to change the bits of the pointer, the system could instead unmap the memory the pointer used to refer to.
On 4/29/21 9:56 AM, Jason McKesson via Std-Discussion wrote:You mean when [vector.modifiers] says that pointers are invalidated, it means storing https://timsong-cpp.github.io/cppwp/n4861/basic.compound#def:value,invalid_pointer into each such pointer?
On Thu, Apr 29, 2021 at 4:31 AM Giuseppe D'Angelo via Std-Discussion
Hello,Um, no. A pointer becoming invalid is not something you can detect.
On 29/04/2021 07:33, Christopher Hallock via Std-Discussion wrote:
I was adding my own concerns about these library clauses beingWell... "sure"? Does this now make std::vector unimplementable in the
underspecified and overly broad. Getting back to your original question,
which is whether library invalidation "sticks", given [basic.life]/8: I
believe it does. If the invalidating operation move-assigns or
copy-assigns the elements, then [basic.life]/8 doesn't even apply
because no new object was created. If the invalidating operation
move-constructs or copy-constructs the elements, then there is room for
ambiguity, but I think the intent is that even in this case, the
invalidation "sticks". I believe things happen in this sequence: 1)
element is destroyed, which automatically invalidates pointers to it; 2)
new element is created in the same place, "resurrecting" the old
pointers via [basic.life]/8; 3) the library clause kicks in and
invalidates the resurrected pointers once more.
C++ language, as it requires implementation "magic" to perform 3)?
Being invalid means that UB will happen if you try to use it. And UB
could include everything "working" as you would expect.
Technically, a pointer being invalid means that it has
implementation-defined behavior to do anything but dereference it ,
so if an implementaion defined 'copying any invalid pointer prints "stop
it" to stdout", then an implementation that did not actually cause
pointers to become invalid on vector reallocation would have observably
different behavior than one that did (of course, such an implementation
could be made conforming by changing the implementation-defined behavior).