Re: [boost] Re: Named Template Params

From: David Greene (greened_at_[hidden])
Date: 2004-12-28 19:05:25

David Abrahams wrote:

>>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?
> 
> 
> Something like:
> 
>    my_template<foo_is<int>, bar_is<long**> >
> 
> IOW,
> 
>    iterator_adaptor<value_type_is<char>, reference_is<char&> >

I remember that part but I recall that there is some additional
setup for the user to do (defining foo_is, perhaps?).  By "user"
I guess I mean class template developer.

>>"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.

Can you give me an example of how that can be done?  From context
provided by the other template parameters?  I'm just trying to
grasp how this works and understand how it compares to NTP,
why NTP might not be the best way to go, etc.

>>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.

Ok, maybe I'm starting to grasp it.  In my particular case, all my
template parameters are integers so I need a way to identify which
integer value is supposed to go where.  That's why I developed the
named template parameters framework and it's not coincidental that
my example passed integer arguments around.  ;)

>>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
>>   solution.
>>
>>- The separation of parameter declaration and default value definition.
>>
>>- Packaging up all parameters into an MPL sequence.  It's not so bad,
>>   though.
> 
> 
> What's not to like about that?

The packaging?  It's just an extra step.  Like I said, it's not a big
deal.  I'm more disappointed that I couldn't hook into the C++ default
template arguments mechanism to pass NTP defaults.

>>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
> satisfied.

Actually, I did some work with iterator_adaptors about a year ago
and I found the named template parameters to be useful.  I specified
everything but I didn't want to care what order I did it in and
the value_type_is<>, etc. gave me visual cues as a developer what
each argument is used for.  I was sad to see this capability gone
in the new library.

I tried to take the idea of NTP from iterator_adaptors and make
it more generic by changing value_is<>, etc. to simple struct
tag classes that can be wrapped with a default value into default_<>
or default_c<> parameters.  Users would then pass param<Key, Value>
pairs as the template arguments.  So the difference in usage is:

Key_is<Value>

vs.

param<Key, Value>

The nice thing about the latter is the client class template using
NTP doesn't have to define searches for Key_is.  It just passes
the set of keys to ntp::key_info<> and does an
ntp::lookup<Key, Params, key_info<> >.

I don't recall how the searching was done with
named_template_params.hpp.  It may just be a matter of syntax for
all I know.  If I have time, I'll grab a copy of the old
iterator_adaptors library and do some comparisons.

I'd think that the same arguments that motivated the named function
parameters library would motivate a named template parameters library.

I appreciate your insight and feedback on this.

                          -Dave