Re: Iterator Adaptor not using traits as template args

From: yahoo_at_[hidden]
Date: 2001-03-02 06:03:54

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:

> Normally, std::iterator_traits<T> is used for inquiry about an
>iterator, not as a way to specify traits for a new iterator.
> When creating a new iterator type, there is often no existing,
appropriate, deducible T for which std::iterator_traits<T> supplies
all the correct traits.

Well, I was not thinking of std::iterator_traits but rather one of:
* a custom traits class already available
* a helper traits class with sensible defaults like yours in the
current iterator_adaptor incarnation.
* a template-generated class when possible
(i.e.: greatest_common_traits< Traits1, Traits2>::ret )
* why not a helper traits class with keyword templates arguments as
it has been discussed.

> though... also note that the category must be specified even when it
can be
> deduced from a base iterator type.
>
Here I understood our difference in point of view.
I do not use iterator adaptor to adapt iterators :-(
My underlying types (set of iterators or plain objects)
won't allow any deduction...

> The example set by the adaptor generators in the library show
substantial
> simplification due to the new interface. Do you have >counterexamples?

Well, I was just advocating for consistency in the way of passing
iterator infos (traits) as template parameters. I see that policy
classes use Traits template argument and code like this does not:

<snip>
template <class Iterator1, class Iterator2, class Policies, class
Value1, class Value2,
    class Reference1, class Reference2, class Pointer1, class
Pointer2, class Category,
    class Distance>
Distance operator-(
    const
iterator_adaptor<Iterator1,Policies,Value1,Reference1,Pointer1,Category,Distance>&
x,
    const
iterator_adaptor<Iterator2,Policies,Value2,Reference2,Pointer2,Category,Distance>&
y)
{
    return x.policies().distance(type<Distance>(), y.iter(), x.iter());
}

</snip>

I realize that policy is used after the iterator is built so
std::iterator_traits<> is available, but why not always pass traits
the same way, as one class.

I also realize that the Standard does express type infos is strustured
ways (traits) as often as I'd like to. But am I the only one to get
tired of endlessly typing "typedef typename XXX::yy yy;"
(At least it will kick me to learn emacs enough to automate it :-) )

>
> That's why there is a release cycle at boost. The iterator adaptor lib
> wasn't released yet. ;-)
>

Please, do not take my reaction as a rant ! I am VERY happy that you
made it available so soon. It samed my time and was fun to use. I
don't expect more !

> > 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.
>
> Why not just use:
is_sensible<std::iterator_traits<iterator_adaptor<...> >
> >::ret
> ??

Well, I think you answered it all, if is_sensible<> takes a Traits
parameter to express some iterator type properties, so should
iterator_adaptor<> for consistency reasons in my opinion.
Even if std::iterator_traits<> is not available.
(boost::iterator_traits_helper< sensible defaults> could be)

Please, do not take this as a rant from some lazy guy who did not
unsertand / bother to note that he was using an pre-release library
and does not want to rewrite code!
I will rewrite it anyway when View template Libray is available ;-)

Thanks again for your excellent work in Boost and iterator_adaptor
especially !

Bernard