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