This is where the conceptual error of the C++ object model shows. A pointer
or reference points to memory, not to an object. The pointer type informs
how that memory should be treated. If the memory remains allocated to the
program, the pointer is valid. If the contents of the memory are valid for
a type, the object of that type in that memory is valid.

Your deciding for all programmers that when they have pointers to vector
elements they "really" mean some theoretical element that wanders around
within the vector is no more valid than if you decided the same for
pointers to array elements. You are breaking people's code or making it
harder for them to work so that you can satisfy yourself about some useless
abstract principle being followed.

On Fri, Apr 30, 2021, 9:33 AM Jason McKesson via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Fri, Apr 30, 2021 at 7:37 AM Giuseppe D'Angelo via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > Hello,
> >
> > On 30/04/2021 01:56, Jason McKesson via Std-Discussion wrote:
> > >
> > > By inserting an object into a vector, you have conceptually changed
> > > the address of all of the objects past that one in the container.
> > > However, any pointers/references cannot themselves move to aim at the
> > > correct object. Therefore, such pointers/references should no longer
> > > be considered valid pointers/references to what they pointed
> > > to/referenced.
> > >
> > > Put simply, a pointer/reference to an element in a container is not,
> > > and should not be considered, a fancy index.
> >
> > I never said that pointers/references/iterators should magically move.
> > In fact, I said that pointers would point to the element that ends up
> > being in the position they were pointing to.
>
> My point is that they *should* "move". A pointer to an element should
> be a pointer to that element and no other element, unless you
> explicitly modify that element. Because the nature of `vector` makes
> that impossible implementation-wise, the only reasonable alternative
> is to make them invalid.
>
> > You're basically arguing that "it is what it is" regarding the lack of
> > such a guarantee. That is, the mental model that `vector` to go with is
> > a mental model that invalidates pointers, even if:
> >
> > * such invalidation is unenforceable (unlike iterators);
> > * such invalidation doesn't actually happen in any implementation (are
> > implementations allowed to have extra capacity on the left to optimize
> > prepend? That makes a mess out of capacity(), but maybe there's an
> > escape hatch/hat trick);
> > * such invalidation cannot even happen because of (new? old?) language
> > rules (unlike iterators, and due to a lack of an ad-hoc
> > `std::invalidate` facility) and therefore it's not usable in
> > optimizations, sanitizers, etc.;
> > * it costs precisely zero for an implementation provide the extra
> > guarantee (in fact, is it already "accidentally" offered today by all
> > implementations?).
> >
> > I'm not sure if I'm 100% convinced. A `vector` isn't an arbitrary data
> > structure, it's a quite specific one, with clear operational semantics.
>
> But it is a container, and it should act like one. Pointers to
> elements in a container should act like pointer to elements in every
> other container, except for when that is made impossible by some
> specific nature of a specific container. And in those cases, those
> pointers should be invalidated; they shouldn't do something weird like
> magically transform into pointers to other elements.
>
> And I'd like to point out that there's not really any practical
> benefit to creating a special rule like this for `vector`. That is, it
> doesn't let you do anything you couldn't do with indices if you know
> you're working with a `vector`. So you should just use indices to make
> it clear to everyone reading your code that you expect the underlying
> elements to shift around.
>
> In any case, you wanted to understand the conceptual reasoning behind
> it, and this is it. You don't have to agree with it, but this is the
> logic behind it.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>