Re: [boost] Standard library Technical Report 2 proposals for Boost libraries

Subject: Re: [boost] Standard library Technical Report 2 proposals for Boost libraries
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-12-17 17:08:06

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