Re: [boost] [parameter] some extensions to Boost.Parameter

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" <stipe-AT-asu.edu> wrote:

> 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
> 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
>
> BOOST_PARAMETER_FUNCTION(
>       (void),
>       foo,
>       tag,
>       (required (arg, int) )
>       (optional
>         (arg2,           double, 1.5)
>       )
>   )
>
> ... and how the expansion of that could be altered?  

Yes.

> 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).

Hm.

> [...]
>
>>>
>>> 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
http://www.boostpro.com