Re: [Boost-users] [mpl] newbie question

24 Feb 2006

      "Peter Dimov" wrote
...
Andy Little wrote:
...
What is the problem with the result  of  plus being
int_ ?
How does the specification of mpl::plus look like in your proposed model?
Firstly the signature  :

namespace boost{ namespace mpl{

    template 
    struct plus;

}}

IOW the function doesnt have more than 2 parameters

Rationale:

The extra parameters are

* unexpected
* a nuisance when specialising for a UDT.
* irrelevant in many uses eg with  mpl::transform.
* lengthen error messages.
* more likely to overflow.

I realise that would break existing code but I bring it up as a discussion
point if mpl was ever the subject of standardisation for example.

Secondly the type of the result

As a workaround to the status quo I would suggest that where the first two
parameters are of the same integral_constant template type and the rest arent
specified by the user ( ie left as the default mpl::na), the template type of
the result should be the same as the template type of the integral constant
parameters.

note: If the first modification was unacceptable then the rule could of course
be extended to further numbers of integral_constant parameters, otherwise if the
first modification was acceptable then the following code is still valid.

Example

    typedef mpl::plus,mpl::int_<2> >::type int_two;
    assert((boost::is_same >::value));

    typedef mpl::plus<
        mpl::integral_c,mpl::integral_c
    >::type long_c_two;
    assert((boost::is_same< long_c_two,mpl::integral_c >::value));

As a refinement  promotion rules  would  add certainty in further cases of
integral_constant combinations. The current spec gives an example indicating
something similar with regard to value_type but AFAIK no wording.

The same rules would apply to mpl::minus,mpl::times, mpl::divides, and logical
operators etc

As far as I know that is the extent of the modifications to the current spec.

regards
Andy Little