Hello,

On 28/04/2021 16:55, Christopher Hallock via Std-Discussion wrote:
> 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.

Apologies; I'm not sure if I understand the counter-counter objection.

I was definitely talking about pointers obtained via the container's own
APIs (data(), or & + operator[]/at(), &*it, etc.), and not pointers that
the stored objects might be tracking themselves (for instance by adding
themselves to some external "registry", or by having a member pointer
equal to `this`, or so.).

Is the objection related about "what happens if the objects stored in
the container use container-API-derived pointers from their
constructors, assignment operators etc. WHILE the container is
performing a modification -- insertion, erasure, etc."?

Thanks,

-- 
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts