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