[boost] Re: Re: [Formal review] Collection Traits library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-05-05 05:09:53

"John Torjo" <john.lists_at_[hidden]> wrote in message news:4098BDCE.6060202_at_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