Re: [boost] Named template parameters

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,
you're out-of-luck.

> Why not just have
> std::input_iterator_tag as the 4th parameter? I know, it's because we
can't
> 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
the
> 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).

-Dave