On Behalf Of David Abrahams Subject: [boost] Re: [named_params] timing trivia and some comments

...

"Matthew Hurd" <matt@finray.net> writes:

...

Been looking at the very cute named_params in the sandbox. Getting around to trying to do some stuff with it. <snip> I'm deeply impressed. Well done Dave and Daniel.

You can thank the good people at Microsoft for that. I don't think we put any special attention on avoiding abstraction penalty other than doing the obvious things (e.g. pass classes by reference).

Design helps and the magic of C++ optimisation ;-)

...

It would be nice if the macro could some how encapsulate the keyword definition so this might be eliminated. struct base_t; struct exponent_t;

namespace { boost::keyword<base_t> base; boost::keyword<exponent_t> exponent; }

struct power_keywords : boost::keywords< base_t, exponent_t> {};

Good point... but we anticipate the keywords for a given library will probably be re-used in several function interfaces, so we can't rightly do it all with a single macro invocation -- you might need to write several lines like the last one, for different functions. We can do something like:

BOOST_NAMED_PARAMS_KEYWORD_DECL((base)(exponent))

to generate the keyword declarations and then something like:

BOOST_NAMED_PARAMS_KEYWORD_SET(power, (base)(exponent))

for each line like the last one.

That would work nicely. Though there might be some benefit in not reusing the keywords and putting them into a namespace with the function and I think ADL might help with the keyword name resolution. Hmm, or does it. I'll try it.

...

The pre-processor trickery to do this is beyond me I'm afraid.

It's not hard, if you're willing to spend the time poring through the PP lib docs. I just worry a little about ending up with a library interface that hides everything behind macros.

...

I am interested in being able to iterate over the parameters extracting keyword_types, argument types and argument values.

Since the parameters can have heterogeneous types, there's no way to iterate over them. It would, however, be possible to "recurse" over the items with something that looks like:

for_each(params, some_templated_function_object)

...

Convenient string names would be good too but I can always uses typeid on the keyword_types.

Why would I want to do this? I would like to use this approach as a way for inserting an intermediary function. Specifically, I would like to call f<direct>(x,y) and have the direct representation called or f<marshal, destination>(x,y) and have an intermediary serialize the params into a block and send it off on a transport where a representation along the

...

f<marshal, source>(x,y) would accept the block in some infrastructure somewhere else. f<queue_for_processing_in_a_thread_pool>(x,y) fits

I'll give it a crack. Though I too am concerned about ending up with a macro mess and little C++. Would be much nicer if there was a generative C++ approach that was suitable. lines of this

...

model too.

Any thoughts?

I guess my first thought is: "Whaa??? What does any of the above have to do with a named parameters library?"

Pretty much nothing. I just like the named_params style of interface and wanted to adopt the approach. I want to build a mechanism where it is easy to build an interface to a function / functor than can have a policy that allows it to be a normal function or something else such as a function in worker pool or a remote function. My desire is to make it easy to represent a function and keep this orthogonal to whether it remote, pooled or local via a policy. For some of the mechanisms I actually would like names for the parameters to help fulfil a protocol requirement, thus the desire for introspection on the names and a look into your neat library.

And then I think: "OK, he wants something that mates the serialization library from Robert Ramey with the new tuples (fusion) from Joel de Guzman".

This was my original thought. To use tuples and Robert's serialization. I haven't looked at the new tuples in fusion. Will do so. The get<0>(mr_tuple) approach is not as nice and it doesn't have a unique name for the param. I'll have a think about this. Which ever approach Robert's serialization will be a key plank.

I can begin to vaguely see a reason to slap a named parameters interface on top of the whole thing, but it seems like you could do that as an afterthought. Am I missing something? I must be.

One extra note for you. There was a couple of typos in the doc. From memory, the order of the arity and the keywords in the macro are transposed in the documentation. Also the docs still refer to params[name | default] rather than p[name|default]. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm@sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.