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-28 17:08:44

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

That's a bit of a surprise.  What kind of difference in compile time are
you seeing?

> and (IMO) cleaner library code

Could you show some examples?

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.

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

> which allows *3*
>
> Implementing this involved splitting the keyword class into
> typed_keyword and untyped_keyword, with the commonalities extracted
> into a keyword_base class.  It also introduces a corresponding new
> macro, BOOST_PARAMETER_TYPED_NAME.
>
> *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,"")
>
> 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?

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

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.

> *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.
>
> I had to hack tagged_argument and arg_list to work with
> delayed_constructor, which was in some ways similar to how
> tagged_argument and arg_list are made to work with the `maybe` class.
> This leads me to believe that tagged_argument and arg_list would
> benefit from having a specified extension interface into which things
> like `maybe` and `delayed_constructor` could hook into, rather than
> being so tightly coupled.
>
>
> The proof-of-concept implementation for all these things can be found at:
> http://svn.boost.org/svn/boost/sandbox/guigl/boost/parameter/
>
> To avoid clashing with Boost.Parameter, I made the above extensions in
> renamed classes (e.g., typed_arg_list and typed_tagged_argument).
>
>
> 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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com