From: Moore, Paul (paul.moore_at_[hidden])
Date: 2001-03-06 08:28:09
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,
> named_traits::iterator_category<std::input_iterator_tag> >
Better, but (from my POV) what's the point in the
named_traits::iterator_category<...> bit? Why not just have
std::input_iterator_tag as the 4th parameter? I know, it's because we can't
support both ways. But as a user who prefers the unnamed approach, why do I
need to make (verbose) concessions to a construct the language does not
I think this is probably one of those "you can't please all of the
people..." cases. In that case, I'd stick with what the language is designed
around (positional parameters).
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 the
iterator adaptor library).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk