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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-05-04 19:08:37

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?

| I don't like the idiom of using begin() and end() for iterators which
| default-constructed denote the end of a range. I think there are very
| few iterator classes which match this concept: std::istringstream,
| filesystem::directory_iterator, anything else?

I assume there would be others. Can anybody mention others?

| 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 ), ... );

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

I find code that would rely on something else to be very subtle.

FWIW, I think there can be made improvements in this area. Dietmar Kuhl has been talking about
using property maps or something to make the requirements for iterator indirection useful in other ways.
The new iterator library by Dave, Jeremy and Thomas might solve such problems. As I see it, we need
to see algorithms that rely on guarantees about reference_of + iterator indirection to implement something better/correct.

br

Thorsten