C++ Logo


Advanced search

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

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Thu, 29 Apr 2021 09:56:22 -0400
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.

Received on 2021-04-29 08:56:34