Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Valentin Ziegler (vziegler_at_[hidden])
Date: 2014-03-24 11:01:41

Hi Adam,

> Btw, do you know the reason for this requirement? I can imagine that some iterator could store a temporary created from data gathered during the traversal. Or when dereferenced return some wrapper/proxy with a pointer to itself or one of its members. But this doesn't convince me.

I do not know of a particular reason. Guess when the ISO committee did the wording for "iterator requirements", they had to say something about the lifetime of a reference returned by an iterator. The only guarantee that can be expressed without further assumptions (e.g., the existence of a parent container) is "reference lifetime == iterator lifetime".

For example, boost's counting iterator did return by reference, not sure if that has changed by now ( https://svn.boost.org/trac/boost/ticket/2640?version=0 ). One could imagine other iterators that are mere proxies to some cached computation or streaming iterators. In my opinion, all such iterators should rather return a value instead of a reference to some internal state, but the standard does not preclude it.

Valentin

--
Valentin Ziegler | vziegler_at_[hidden]
Senior Software Engineer
We are looking for C++ Developers: http://www.think-cell.com/career
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Sch?dl