Subject: Re: [boost] [parameter] some extensions to Boost.Parameter
From: David Abrahams (dave_at_[hidden])
Date: 2008-10-29 19:34:28
on Tue Oct 28 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
> On Tue, Oct 28, 2008 at 2:08 PM, David Abrahams <dave_at_[hidden]> wrote:
>> on Tue Oct 28 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
>>> I have found these extensions useful when
>>> using ArgumentPacks directly rather than using Boost.Parameter macros
>>> like BOOST_PARAMETER_FUNCTION, BOOST_PARAMETER_CONSTRUCTOR,... (I am
>>> using the library in this particular way because of reduced compile
>> That's a bit of a surprise. What kind of difference in compile time are
>> you seeing?
> Nothing too dramatic. In the following experiment:
> ... the results for a simple test scenario gave the following times:
> user: [test_parameter_compilation.o] 0.000195
> system: [test_parameter_compilation.o] 0.000030
> user: [test_parameter_dispatch_compilation.o] 0.000555
> system: [test_parameter_dispatch_compilation.o] 0.000041
> test_parameter_compilation corresponds to using ArgumentPacks
> directly, and test_parameter_dispatch_compilation uses
> BOOST_PARAMETER_CONSTRUCTOR (perhaps for BOOST_PARAMETER_FUN the
> difference is even smaller or non-existent)
>>> and (IMO) cleaner library code
>> Could you show some examples?
> Sure. My use case is a GUI library that tries to make it easy to
> implement new widgets. Widgets can be put together by stacking
> behaviors in an inheritance chain. For example, a button uses the
> following base class:
> class button;
> > > > button_base_type;
> - each of the view:: templates listed adds a behavior to the button
> widget, and they are implemented by inheriting the next behavior in
> the chain (in this case, button will inherit active_colored which will
> inherit solid_background which will inherit clickable which will
> inherit positioned...). Here is the button constructor:
> class button : public button_base_type
> typedef button_base_type base_type;
> template<typename ArgumentPack>
> button(const ArgumentPack &args)
> : button_base_type(args)
> I.e., the constructor takes an ArgumentPack and forwards it to its
> base class. The base class will perhaps pick off some arguments and
> forward the pack to its base, etc. For example, solid_background does
> template<typename BaseView=base>
> class solid_background : public BaseView
> typedef BaseView base_type;
> template<typename ArgumentPack>
> solid_background(const ArgumentPack &args)
> : base_type(args)
> , m_background_color(args[_background])
> I have found that the direct use of ArgumentPacks makes this
> inheritance-chaining design quite nice/clean to implement. AFAICT,
> using the macro-based interface would have required two classes per
> view/behavior (an implementation class, and a class that uses
> BOOST_PARAMETER_CONSTRUCTOR) - this is because any of these classes
> can be the top-level class. That alone was reason enough for me not
> to investigate that route further - I'm not sure whether any
> difficulty would arise from having to specify that a class can receive
> a parameter intended for it, or intended for the base class.
I don't see why that means the top-level class needs to have an
class button : public button_base_type
typedef button_base_type base_type;
// takes up to 12 parameters
MY_GUI_GENERATE_CTOR(button, 12, button_base_type);
>> Answers to these two questions could help me evaluate the merits of
>> integrating this functionality into the library.
>>> (although user-side code takes a slight hit)).
>> That shouldn't be necessary, even if you forego the macros.
> I think I'm stuck with requiring double parenthesis,
You shouldn't be.
> and I don't know how to take advantage of, e.g., deduced parameters.
They are only applicable when the types of possible arguments are
sharply distinct. Is that your situation?
>>> Here are brief descriptions of the extensions:
>>> *1* Keywords/Tags with fixed types
>>> These are intended for keywords/tags that are always associated with a
>>> certain type of argument. operator= of a fixed-type keyword always
>>> return a tagged argument whose value_type is the fixed type.
>>> This has the benefit of moving any type conversions to the call site,
>> Might be interesting if we can integrate that into the macros for the
>> cases when you specify a fixed type. This sounds vaguely similar to
>> what we have to do for the Python binding functionality, except that we
>> do the "type fixing" post-facto.
> I think this would be relatively easy and safe (in a non-breaking
> change sense) to add in.
Looking forward to seeing that.
>>> BOOST_PARAMETER_TYPED_NAME_WDEFAULT(label,const std::string,"")
>>> If a ArgumentPack args does not contain an explicit value for _label,
>>> args[_label] will return std::string(""). I'm not sure what the right
>>> response to e.g., args[label|"something"] should be.
>> Compilation error?
> Perhaps. I think the alternative that Andrey Semashev suggested is
> also interesting, where "something" is chosen if the label is not
> explicitly provided.
Fine with me; that would've been the other obvious choice.
>> Ohhh.... so you're saying any two argument packs with the same keywords
>> and types would be inter-convertible, regardless of argument order?
>> That makes some sense.
> Yes - a source pack could be converted to a target pack type as long
> as the source contains a superset of the tags needed for the target
> (or any missing tags have a default-default value).
And, I hope, the types of the source pack have to be convertible to
the types of the target pack.
>>> *4* Overloading operator() for typed keywords
>>> Instead of writing, e.g.:
>>> window (( _size=size_type(100,100), _position=position_type(0,0) ))
>>> , we can write
>>> window (( _size(100,100), _position(0,0) ))
>> Pretty cool.
>> This looks like it overlaps with deduced parameters a lot, though.
> Yes, there is overlap. If deduced parameters were available (are
> they, without the macros?),
> you could do:
> window (( size_type(100,100), position_type(0,0) ))
> except `window (( _size(100,100), _position(0,0) ))` would also work
> when size_type and position_type are the same type.
>>> Please let me know if there is any interest.
>> I'd have to see what Daniel thinks. It would also be interesting to
>> know if anyone else in the community has wanted this functionality.
> Thanks for taking a look!
Always nice to have someone else carrying our work forward!
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk