Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-13 22:57:31

Daniel Frey <d.frey_at_[hidden]> writes:

> On Sun, 13 Oct 2002 19:29:14 +0200, David Abrahams wrote:
> > Daniel Frey <daniel.frey_at_[hidden]> writes:
> >
> >> David Abrahams wrote:
> >> >
> >> > Daniel Frey <daniel.frey_at_[hidden]> writes:
> >> >
> >> > A const& is not a transparent replacement for a value in other ways.
> >> > Consider:
> >> >
> >> > const iterator& x = c.end();
> >> > c.insert(start, finish);
> >> > // is x valid here, or dangling?
> >>
> >> 'const iterator x = c.end();' won't be any better, would it? Maybe I
> >> need some more explainations here :))
> >
> > The question has to do with whether a const& _return_ _value_ is a
> > transparent replacement for a by-value return. If c.end() returns a
> > value, x binds to the temporary and keeps it alive for the duration of
> > the scope. If c.end() returns a const reference, mutating functions on c
> > may invalidate or change the object to which x is bound.
> If the iterator is stored inside of the container, this is not a problem,
> is it? And today, it's also a problem as iterators (even the objects) are
> invalidated and you are not allowed to use them after an insert().

Not every container behaves like vector. Imagine c is a set for

So I put the wrong comment at the end of the example. The problem in
this case is not invalidation, but that x now refers to something
different than it would have if c.end() returned by value. Iteration
over [c.begin(),x) covers a different range.

My point once again: const& returns are not a transparent replacement
for by-value returns.

> Anyway, my current impression is, that we have a consensus about the NRVO
> itself. I would suggest that we add it without the const return values
> and discuss the const-topic separatly. Is this OK for everyone?


           David Abrahams * Boost Consulting
dave_at_[hidden] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at