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).

-- 
Jason Cobb