Hi,

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.

Cheers,
Lénárd


-------- Original Message --------
From: "language.lawyer--- via Std-Discussion" <std-discussion_at_[hidden]>
Sent: June 23, 2021 8:40:18 AM GMT+01:00
To: Bo Persson via Std-Discussion <std-discussion_at_[hidden]>
Cc: language.lawyer_at_[hidden]
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:
>> On 29/04/2021 17:08, Jason Cobb via Std-Discussion wrote:
>>> On 4/29/21 9:56 AM, Jason McKesson via Std-Discussion wrote:
>>>> On Thu, Apr 29, 2021 at 4:31 AM Giuseppe D'Angelo via Std-Discussion
>>>> <std-discussion_at_[hidden]> wrote:
>>>>> Hello,
>>>>>
>>>>> On 29/04/2021 07:33, Christopher Hallock via Std-Discussion wrote:
>>>>>> I was adding my own concerns about these library clauses being
>>>>>> 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.
>>>>> Well... "sure"? Does this now make std::vector unimplementable in the
>>>>> C++ language, as it requires implementation "magic" to perform 3)?
>>>> Um, no. A pointer becoming invalid is not something you can detect.
>>>> 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 [0],
>>> 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).
>>
>> 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?
>
> 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.
I'm asking about C++ abstract machine behavior, not about how it may be implemented.

-- 
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion