Subject: Re: [boost] [parameter] some extensions to Boost.Parameter
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-10-30 11:41:31
On Wed, Oct 29, 2008 at 4:34 PM, David Abrahams <dave_at_[hidden]> wrote:
> on Tue Oct 28 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
>> 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
> ArgumentPack ctor.
Every class needs a constructor that takes an ArgumentPack because it
can be inherited from, and needs to be able to receive the
ArgumentPack from the derived class. If I wanted to allow users to
call the constructor in a more friendly way, then every class that
could be a top-level class would also need a constructor like you
suggest below (and 'every class' would need to turn into a pair of
classes because we can't delegate to another constructor in the same
Ideally, I would want to allow things like this:
some_window << new colored_block(...);
BUT... I might have other reasons why I might require a boiler-plate
top-level class, in which case I might do something like what you
> 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);
does MY_GUI_GENERATE_CTOR expand to
button(const T0 &t0)
template<typename T0, typename T1>
button(const T0 &t0, const T1 &t1)
: button_base_type((t0, t1))
>> 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?
No, I was just curious in general.
>>>> 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.
I'm sorry, I think I misunderstood your comment. I thought you were
talking about adding something to the library that allows things like
BOOST_PARAMETER_TYPED_NAME(arg, int) - which is easy and I have done.
But are you talking about
(required (arg, int) )
(arg2, double, 1.5)
... and how the expansion of that could be altered? I looked at the
preprocessing file but got pretty lost, I think it might take me a
while before I understand how it works.
>>> 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.
I've been using this with typed keywords, in which the types should be
identical if the tags match. When conversions are necessary, because
tagged_argument stores the argument by reference you end up with a
dangling reference because the converted temporary goes out of scope
before the function actually gets called. If you wanted conversions,
you would need tagged_argument to store by value at least in this case
(in which case it might be more efficient for arg_list to store the
tagged_argument by reference... but I'm not sure whether that would
run into the same temporary lifetime problems or other issues).
>> Yes, there is overlap. If deduced parameters were available (are
>> they, without the macros?),
How? In order for the following to work:
window (( size_type(100,100), position_type(0,0) ))
...I would at least have to overload the comma operator for these two
types to return... what? Or, if I used something like the
MY_GUI_GENERATE_CTOR macro and took `window (size_type(100,100),
position_type(0,0) )`, how does the constructor assemble the
ArgumentPack from the two types?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk