Re: Iterator Adaptor not using traits as template args

From: yahoo_at_[hidden]
Date: 2001-02-28 03:15:51

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> 
> 
> In nearly all the examples we could think of, the amount of typing
needed to
> actually use iterator_adaptor was considerably reduced. Can you give
an
> example that shows how things have become worse?
> 
> We're also seriously considering moving the Pointer parameter to the
end of
> all type parameter lists (since it is only needed for compilers
without
> partial specialization), and of removing the Pointer and Reference
> parameters from the _pair_generators (since these can always be
deduced for
> a const/non-const pair of iterators).
> 

Well, I did not really considered the amount of typing, because I'm
afraid that I'm not a good enough programmer to be slowed by my typing
speed :-(
At first, it was just that using iterator traits to describe iterator
properties just "felt right" to me (that's what I use in my own code).
Sure it makes another class template, but I think that there is no
additionnal complexity as it is a known (I would say Standard) idiom.
I mean that we don't have std::value_type< typename Iterator>
std::pointer<typename Iterator> et al. thoses properties are grouped
together in std::iterator_traits<> so that is the standard way of
 expressing iterator properties. We can expect Boost library users to
know it, and the principle of least surprize will lead they (us, me
included) to believe that iterator properties are expressed with a
traits class (default being provided by the Standard) rather than
an ORDERED (:-() set of 5 classes.

As the exemple is set by the standard, we can expect that people
needing custom properties will express them using traits so
having to pass typename traits::value_type, typename
traits::reference, typename traits::pointer
 etc... will not buy them anything. The others either do not need
customization (no problem) or could just use a
iterator_traits_helper<...> with your default parameters.

The ease of use is also ease of reuse (of existing code), and I think
that it would have been easier for me to adapt code from current
interface to the old one(grouping templates arguments in one
iter_traits_helper<>) than the other way (splitting traits, I cannot
easly decide which argument to keep so I must use all of them :-( )

Furthermore, I think it could be a useful addition to have
some template meta-code to manipulate / check iterator properties
(for exemple common_properties< Traits1, Traits2>::traits,
are_compatible<Traits1, Traits2>::ret, is_sensible<Traits>::ret)
and this is most certainly cleaner with encapsulation of thoses
properties in traits.

Anyway, nothing would prevent me from using BIAL, so don't
take this for a rant !

Bernard
(just hoping no major bug got fixed since 1.22 :-) )