Date: Wed, 23 Jun 2021 09:35:35 +0300
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?
> 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?
Received on 2021-06-23 01:35:41