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,
> 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? 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
support?
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).
Paul