From: David Abrahams (dave_at_[hidden])
Date: 2004-12-27 20:08:32
David Greene wrote:
> David Abrahams wrote:
>> There has already been a released named_template_params.hpp in
>> boost/detail "forever".
> I know this used to be used by the old iterator_adaptors. I can't
> quite remember what the interface to named_template_params was
> and it's a little difficult for me to envision given just the header
> file. Got an example laying around somewhere?
my_template<foo_is<int>, bar_is<long**> >
iterator_adaptor<value_type_is<char>, reference_is<char&> >
>> IMO named template parameters are unweildy in C++. I prefer "unnamed
>> template parameters" like those described in
> "Boost.Python determines the role of the argument from its type."
> So does that mean that this idiom can only be used when each
> argument is of a distinct type?
Strictly speaking, no. You're okay as long as it is possible to know,
when you are passed some type X twice, which two "logical" template
parameters are intended.
> I realize that this can be made
> to happen by wrapping each argument in a unique class, but isn't
> that exactly what named template parameters is?
It really depends on the interface of the outer template. If it's truly
general and there's no restriction on the types of its arguments or
their relationships, then you do need to resort to xxxx_is<...> style
wrappers everywhere. Otherwise, you may be able to avoid those wrappers
in some or all places.
> The use of what I've got working now is shown below. Things I don't
> like about this include:
> - Necessity of passing key_info<> to lookup<>. I tried to do this
> through default template args but I couldn't come up with a working
> - The separation of parameter declaration and default value definition.
> - Packaging up all parameters into an MPL sequence. It's not so bad,
What's not to like about that?
> Would anyone find this useful? Obviously it will need some work. I'd
> like to clean up the syntax some if possible.
The reason we dropped the named template parameter interface to iterator
adaptors was that nobody was using it. The default computation was so
complicated that most iterator authors wanted to specify all the
parameters explicitly. So before we make NTP into a real library I'd
like to see it pass some real-world usability tests. If there was at
least anecdotal evidence that people were using and liking it, I'd be
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk