C++ Logo


Advanced search

Re: On "transparently replaceable" in std::vector operations

From: Bo Persson <bo_at_[hidden]>
Date: Wed, 23 Jun 2021 09:06:33 +0200
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.

Received on 2021-06-23 02:06:52