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
> 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
> 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:
template <class Iterator1, class Iterator2, class Policies, class
Value1, class Value2,
class Reference1, class Reference2, class Pointer1, class
Pointer2, class Category,
return x.policies().distance(type<Distance>(), y.iter(), x.iter());
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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk