Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk