From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-06 08:58:19
----- Original Message -----
From: "Moore, Paul" <paul.moore_at_[hidden]>
> From: David Abrahams [mailto:abrahams_at_[hidden]]
> > At first glance, I tend to fall in the same camp, which is
> > why I'm pushing for this.
> > but how about this "new usage", which I think is achievable:
> > iterator_adaptor<int*, default_iterator_policies,
> > named_traits::value_type<int>::category<std::input_iterator_tag> >
> > but also (equivalently) this:
> > iterator_adaptor<int, default_iterator_policies,
> > int,
> > named_traits::iterator_category<std::input_iterator_tag> >
> > Better?
> Better, but (from my POV) what's the point in the
> named_traits::iterator_category<...> bit?
The iterator_adaptor template has seven parameters, many of which can be
defaulted. People have a hard time figuring out which is which. Also, if you
want to use the default for parameter 3, but need to provide parameter 7,
> Why not just have
> std::input_iterator_tag as the 4th parameter? I know, it's because we
> support both ways.
Actually, I'm arguing that we can support both ways.
> As a side issue, what's the cost of all this in implementation complexity?
> In risk of breaking on less-than-100%-conforming compilers? I tend to side
> with Beman, in looking at this as an interesting research issue, but
> probably premature for inclusion in Boost. (The parameter handling, not
> iterator adaptor library).
There's certainly no cost to providing the generator class in parallel with
the main iterator_adaptor. I'm sure there's some cost to adding this to
iterator_adaptor. On the other hand, I'm not sure it amounts to much more
than the cost of backwards-compatibility support Alexey came up with for
operators.hpp (read the docs for details).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk