|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2001-02-26 18:03:36
----- Original Message -----
From: <yahoo_at_[hidden]>
> Hi,
> I was statying out of sync for too long, and a recent cvs checkout
> gave me the current itarator adaptor. I was surprized to see that
> the template boost::iterator_adaptor<> does not take a traits class
> as the last argument, it used to do.
> I thought that packing thoses types for ease of use was the whole
> point of traits.
> A quick search in the CVS Web interface (great tool) tells me that
> the switch occured two weeks ago (rev 1.22):
> "Removed traits argument from iterator_adaptor<> and switched to explicit
trait
> specification for maximum ease-of-use."
>
> I'm afraid I do not get the gain in ease of use... (even the docs
> seem to acknowledge that seven args is somewhat stretching the limit.)
> It is easier for me to have a template iterator_traits_helper<> that
> I can fill with Value, Reference, Pointer, Category and Distance (and use
the same sensible defaults that iterator_adaptator provides)
> when I have types and I want traits, than use traits::value_type,
traits::reference, traits::pointer, traits::iterator_category and
traits::difference_type
> when I ave traits and I want types (like in the current iterator_adaptor
incarnation). I 'm still a fan of Iterator Adaptor Library, so thanks for
the good work !
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).
> BTW, is there any plan for use of the library in View Template Library
(another great library to come that will make me throw piles of code :-)?
I can't speak for VTL, sorry!
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk