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

Subject: Re: [boost] Standard library Technical Report 2 proposals for Boost libraries
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-12-15 16:04:45

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?


My current problem is that "std::inplace_merge" for gcc > 4.4 no longer works for iterators returning proxy objects: <http://lists.boost.org/MailArchives/ublas/2011/12/5123.php>. While it wouldn't be difficult to fix the code, it's unclear to me how the underlying concept should look like:

Thomas Klimpel wrote:
> The attached patch modifies "std::inplace_merge" appropriately...
>
> The issues boils down to the fact that for "Forward Iterators",
> the return value of "*a" must be convertible to "T&"
> (see for example <http://stdcxx.apache.org/doc/stdlibref/iterators.html>).
> But a temporary value cannot bind against a non-const reference,
> so these requirements can only be satisfied if the return value of "*a"
> actually has the type "T&" (please correct me if I'm wrong).
> But this makes it impossible to use proxy_objects with iterators,
> and hence makes many actual usages of iterators (like this one here) impossible,
> or at least not standard conform (again, please correct me if I'm wrong).

MSVC probably has less problems with proxy objects, because it can bind temporary values against non-const references.

I wonder about the required properties of "iterator_traits<_ForwardIterator>::reference" that would capture the most typical use cases of proxy objects. In the case above, "iterator_traits<_ForwardIterator>::value_type" and "iterator_traits<_ForwardIterator>::reference" are identical, and refer to a proxy class with a "non-trivial" destructor. I have the impression that there are certain "hard to formalize" expectations with respect to the lifetime of the proxy object, but I may be wrong.

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...

Regards,
Thomas