Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-05-05 05:11:26

Thorsten Ottosen wrote:

>Hi John,
>Thanks for you review.
>| about the name of the library:
>| Not sure why it's called collection traits, since IMO it should better
>| be called either sequence traits, container traits, range traits or
>| array traits.
>1. sequence traits is part of Pavol's string library, IIRC.
>2. there is no array concept that quite fits the functionality
>3. its name was changed to collection traits because we found out that Jeremy had made such a concept
>range traits is not to bad. I would love to hear other's oppinion about it. Some has said
>"range" is too generic since we are strictly speaking talking about iterator-ranges. Hence Pavol
>named his class in the string library iterator_range. So maybe iterator-range traits? Anyway,
>let' hear what people think.
>| quite ok. Small suggestios:
>| - in collection_traits.html/"Semantics"
>| You say '...c is an object of that type. SC will denote a standard
>| container...'. I think bullets would be quite ok here.
>yes, Pavel already wanted one.
>| 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;

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

>at leastv some people wanted that idiom to work.
>| 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...


John Torjo
-- john_at_[hidden]
-- - viewing/filtering logs is just too easy!

Boost list run by bdawes at, gregod at, cpdaniel at, john at