RE: [boost] Re: [named_params] timing trivia and some comments

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-03-03 16:52:03

> On Behalf Of David Abrahams
> Subject: [boost] Re: [named_params] timing trivia and some comments
> 
> > "Matthew Hurd" <matt_at_[hidden]> 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'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.

> > 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
lines of
> > 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
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_at_[hidden]
+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.