Boost logo

Boost :

Subject: Re: [boost] [parameter] some extensions to Boost.Parameter
From: David Abrahams (dave_at_[hidden])
Date: 2008-10-30 14:15:25

on Thu Oct 30 2008, "Stjepan Rajko" <> wrote:

> On Wed, Oct 29, 2008 at 4:34 PM, David Abrahams <dave_at_[hidden]> wrote:
>> on Tue Oct 28 2008, "Stjepan Rajko" <> 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
> class, no?).
> Ideally, I would want to allow things like this:
> typedef
> view::solid_background<
> view::positioned<>
> > colored_block;
> 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
> suggest below.

Sorry, maybe I didn't understand correctly, but I thought classes like
button below were "top level" and were not chained like the elements of
button_base_type. If that's wrong *and* classes like button have
interesting construction behavior of their own, then yes, they would
have to both pass argument packs through and have a base class to which
they can delegate "real" construction.

>> class button : public button_base_type
>> {
>> public:
>> 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
> template<typename T0>
> button(const T0 &t0)
> : button_base_type((t0))
> {}
> template<typename T0, typename T1>
> button(const T0 &t0, const T1 &t1)
> : button_base_type((t0, t1))
> {}
> ...
> ?

Something like that.

> [...]
>>> 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.

Look at the documentation for Boost.Python's def(...) function and
class_<...> template.

>>>>> 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
> (void),
> foo,
> tag,
> (required (arg, int) )
> (optional
> (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.

Daniel is responsible for most of that code; maybe he can help.

> [...]
>>>> 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?),
>> Yes.
> How?

Sorry, no time to explain right now, but you can see examples in
libs/parameter/test/deduced.cpp and
libs/parameter/test/deduced_dependent_predicate.cpp. I suggest also
reading the reference docs on ParameterSpec's

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at