[boost] Re: Named Template Params

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-28 19:48:08

David Greene wrote:
> 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.

Yes.  But I don't remember what was required.  You can always look back
through the CVS history for boost/iterator_adaptor.hpp

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

That, and the requirements of the template.  For example, if you have a
template foo that takes up to 3 logical parameters.

  Parameter A, if supplied, must be a class type.
  Parameter B, if supplied, must be the same as or derived from A.  It
defaults to A.
  Parameter C, if supplied, must be a pointer or smart pointer to B

if I write foo<bar,bar>, you can tell that both A and B are bar, so it
doesn't really matter which one is which ;-)

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

Okay.  I guess there's no restriction on the relationships among those
integers?

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

Hm, interesting.

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

The bad thing about it is that it's more verbose for the ultimate user.
 The ultimate user is more important than the designer of the client
class template.

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

Unless the syntax turned out to be too unwieldy.

> I appreciate your insight and feedback on this.

One last thing:  I bet the named function parameters library and the
named template parameters library could be made to share most of the
same core machinery.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com