Boost logo

Boost :

Subject: Re: [boost] [parameter] some extensions to Boost.Parameter
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-10-28 18:07:46


David Abrahams wrote:
> on Tue Oct 28 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
>
>> Hello,
>>
>> I've played with some extensions to Boost.Parameter and would like to
>> know if there is any interest to have any of them polished / rolled
>> back into the library.tions 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 one would be interesting. I was always puzzled of which type of
argument I get when using named arguments with a default.

>> *2* Default-default arguments
>> When a keyword always has the same default value, I found it useful to
>> put the default value into the Tag definition (in the form of a static
>> member function that returns that default value). The definition is
>> made using a macro - this is an example use case:
>>
>> BOOST_PARAMETER_TYPED_NAME_WDEFAULT(label,const std::string,"")

This would be great, too.

>> 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?

IMO, it would be better if the "something" value overrode the
default-default value designated in the macro above. The keyword can be
used with more than one function and some of the functions may want to
use different default values.

>> *3* Make ArgumentPacks constructible from other ArgumentPacks.
>
> Aren't they already?
>
>> I basically added a constructor to arg_list that does allows something
>> like the following:
>>
>> // this will return an appropriate arg_list type, containing four tagged_args
>> // the four tags are all typed (*1*) and with default default values(*2*)
>> typedef argument_pack<tag::label, tag::size, tag::position,
>> tag::background>::type
>> argument_pack_type;
>>
>> window(const argument_pack_type &args);
>>
>> In the above case, e.g., window(( _label="label",
>> _size=size_type(100,100) )) would call window with default-default
>> values for position and background.
>>
>> The benefit here is that the implementation of window doesn't need to
>> be templated (which is helpful in some cases), and you don't need to
>> write any forwarding functions (or use BOOST_PARAMETER_FUN).

That's very nice. Could be very useful if one wants to hide the function
into a separate cpp.

>> *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.
>
>> I accomplished this by adding a delayed_constructor class which holds
>> references to the arguments (e.g., 100, 100) and is convertible to the
>> Tag's value_type (e.g. size_type). The 'conversion' is done
>> constructing an instance of the value_type using the arguments. The
>> delayed_constructor is then stored in a tagged_argument object instead
>> of the usual reference to the value_type.

Do I understand correctly that in the latter case "window ((
_size(100,100), _position(0,0) ))" the arguments are not actually
constructed unless they are requested in the window constructor? If so,
this is just great! Looking forward to see it in the official
Boost.Parameter library.

What I'm also missing is the ability to iterate through an argument pack
with the ability to acquire argument names. Basically, I want to be able
to transform an argument pack into something like a map< string, any >.
I can see there is some support for argument names, but I don't see how
I could iterate through the argument pack.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk