on Thu Dec 15 2011, Thomas Klimpel <Thomas.Klimpel-AT-synopsys.com> wrote:
Dave Abrahams wrote:
Well, we should really reconsider the relevance of iterator_traits in light of the existence of decltype. I would like to take another whack at the iterators library but probably won't have time until after the Kona meeting.
Any chance that the "Iterator Access Concepts" can be improved/extended? At <http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/iterator_concepts.html>, the following concepts are defined: Readable Iterator Writable Iterator Swappable Iterator Lvalue Iterator
Would it make sense to complement the "Swappable Iterator" concept by a "Movable Iterator" concept?
No! As I was saying in another message, these concepts are wrong and too granular. Note that I'm *not* arguing against any new system of concepts supporting movability. I'm just saying that the whole thing needs to be reconsidered. Read http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf which probably has the latest work in this area.
Did somebody (like Herb Sutter) already came up with an explanation why "smart references" are impossible in C++03? Then I could stop trying to figure which requirements/concepts they would have to satisfy...
Well... there's always the lack of an operator.(); that's everyone's favorite reason. IMO operator.() doesn't really solve the problem: template <class T> void f(T,T); iterator_traits<I>::value_type v; f(v, *it); // no matching overload if *it is a proxy -- Dave Abrahams BoostPro Computing http://www.boostpro.com