"John Torjo" <john.lists@torjo.com> wrote in message news:4098BDCE.6060202@torjo.com... | Thorsten Ottosen wrote: | >| I love the result_iterator_of. Very useful. | > | >ok, originally I only used this with buggy compilers that could not differentiate between | >const& and & overloads. So you could instead have just one function with a & parameter. | >So you loosed the the binding of rvalues. May I ask what you use it for? | > | > | when designing templated classes | | template<class container> struct widget { | typedef result_iterator_of<container> iterator; | }; I see :-) I hadn't thought of that. I'll add a note to the docs. Is it a problem that result_reference_of<> is not available? | >| Maybe we could make it | >| more explicit, when using such iterator classes, to have a different set | >| of functions: end_it, begin_it? | > | >perhaps. we loose the possibility of using | > | >rng::copy( istream_iterator<char>( is ), ... ); | > | > | > | instead of istream_iterator, just make an istream_range class. It's more | consistent IMO. I presume you mean rng::copy( istream_range<char>( is ), ... ); ? | >at leastv some people wanted that idiom to work. I don't know how to settle this. I remember at least Alisdair wanted direct iterator support. So instead of intrinsic support for iterators in collection-traits we would make a range class for each such iterator-type. The benefit would be, you would argue, that we needed that range class anyway. Some would say they don't need a range class at all, so its just extra work. As far as my implementation would be concerned, it would simplify things a great deal. I would have to write code to recognize each type of iterator because a std::iterator<...> partial template speciaization will not pick up iterators derived from std::iterator<...>. Anyway, if yours and Matthew's range lib will provide range_adapters that makes it super easy to define a range for such iterators, I don't see why I shouldn't just throw my iterator support away. [remark: I see two distinct libs emerging in your work: (1) range-stuff (2) range algorithms] | >| Since we have value_of, iterator_of, etc., why not reference_of, | >| const_reference_of? | > | >As I write in the faq, reference_of<T>::type can just be value_type_of<T>::type &. | > | > | > | As I remember, that's not necessary true for new iterator types... True. I don't think it is holds for existing iterators. But it must be convertible value_type. Hence const reference_type_of<T>::type& can be used to bind a temporary. I just don't see how coding with reference_type_of<T>::type in an algorithm will buy you anything. I might be wrong. br Thorsten