Date: Wed, 28 Apr 2021 10:55:53 -0400
On Wed, Apr 28, 2021 at 10:38 AM Christopher Hallock <
christopherhallock_at_[hidden]> wrote:
>
>
> On Wed, Apr 28, 2021 at 10:34 AM Christopher Hallock <
> christopherhallock_at_[hidden]> wrote:
>
>> On Tue, Apr 27, 2021 at 11:02 AM Giuseppe D'Angelo via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> [vector.modifiers] says that inserting an element at position `p`
>>> invalidates all iterators, references and pointers from position `p`
>>> onwards.
>>>
>>> I'm wondering why there's such a requirement for pointers (and
>>> references) [...]
>>>
>>
>> This kind of Library provision, saying that iterators, pointers, and
>> references to elements are invalidated upon condition X, seems overly broad
>> even if you don't care about using pointers in an "index-like" way, because
>> it means you can't safely use an element type that stores (and properly
>> updates across moves/copies) the 'this' pointer as a member. I suspect that
>> the real intent of this kind of provision is that it only applies to
>> iterators, pointers, and references obtained through the container's API.
>>
>
> Gah, never mind. On further reflection, this is not actually a problem
> because the member would be overwritten on copy/move.
>
On even further reflection, I retract my retraction. It would definitely
be a problem if the invalidation occurs after the elements are
moved/copied. It would also be a problem if the invalidation occurs
beforehand and the move/copy operation involves indirecting through the
original element's pointer member.
christopherhallock_at_[hidden]> wrote:
>
>
> On Wed, Apr 28, 2021 at 10:34 AM Christopher Hallock <
> christopherhallock_at_[hidden]> wrote:
>
>> On Tue, Apr 27, 2021 at 11:02 AM Giuseppe D'Angelo via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> [vector.modifiers] says that inserting an element at position `p`
>>> invalidates all iterators, references and pointers from position `p`
>>> onwards.
>>>
>>> I'm wondering why there's such a requirement for pointers (and
>>> references) [...]
>>>
>>
>> This kind of Library provision, saying that iterators, pointers, and
>> references to elements are invalidated upon condition X, seems overly broad
>> even if you don't care about using pointers in an "index-like" way, because
>> it means you can't safely use an element type that stores (and properly
>> updates across moves/copies) the 'this' pointer as a member. I suspect that
>> the real intent of this kind of provision is that it only applies to
>> iterators, pointers, and references obtained through the container's API.
>>
>
> Gah, never mind. On further reflection, this is not actually a problem
> because the member would be overwritten on copy/move.
>
On even further reflection, I retract my retraction. It would definitely
be a problem if the invalidation occurs after the elements are
moved/copied. It would also be a problem if the invalidation occurs
beforehand and the move/copy operation involves indirecting through the
original element's pointer member.
Received on 2021-04-28 09:56:09