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

From: Andy Little (andy_at_[hidden])
Date: 2006-02-24 08:35:40

"David Abrahams" wrote
> "Andy Little" wrote
>> "David Abrahams" writes
>>
>>> The result of the transform is only required to be "concept-identical"
>>> to the result you're looking for.
>>
>> IMO that behaviour is sloppy. I see no reason why (at least)
>>
>> boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
>
> Patches welcome, and all that.  If you can figure out how to do it
> without greatly complicating the library, I'm sure Aleksey would be
> glad to adopt your code.  Until then, I'll thank you not to sling
> words like "sloppy" around so blithely.

What can I say? I acknowledge that mpl is a monumental piece of work .
Wonderful... but far from perfect.

In this case it looks trivial to change the int_ plus behaviour...

#include <boost/mpl/int.hpp>
#include <boost/mpl/plus.hpp>

namespace boost{namespace mpl{

template <int N1, int N2  /* Nn...*/>
struct plus<int_<N1>,int_<N2> /* Nn...*/>{
    typedef int_< N1 + N2 /* Nn...*/> type;
};

}}

#include <iostream>
int main()
{
    using boost::mpl::plus;
    using boost::mpl::int_;
    typedef  plus<int_<1>,int_<2> >::type res;

    std::cout << typeid(res).name() <<'\n';
}

/*
    output: boost::mpl::int_<3>
*/

Meanwhile mpl causes other work dependent on it ( see below) to be more
complicated to suit it.  This seems to have been done this way because it  makes
the implementors
life a bit easier ( as you allude to below), but the user suffers IMO because
mpl doesnt follow the golden rule of least surprise ( again as you allude to
below)  in this case as the OP has discovered!

>> mpl models itself on runtime C++ but in this case it deviates from following
>> runtime behaviour for no real benefit. Note also that tightening the
>> behaviour
>> wouldnt break any conforming code ;-)
>
> In the user's case, the real benefit is that it drastically reduces
> the number of lines of implementation code in the library, which has a
> real impact on the library's usability.

All I can say is that I was  *a user*.

 It certainly had an effect on useability of my pqs library. It had a huge
effect on compile times because large complicated templates **representing the
same sequence** kept being differently represented. There was a jump in
compilation times from typically 4 seconds to 30 or so, as well as getting Fatal
error messages  from the compiler on relatively small code samples that the
compiler had run out of keys.  The use of mpl  turned the pqs library from
something enjoyable to use to something unusable.  I am much happier now that I
have all but eliminated use of mpl in my physical quantities library . Having
submitted pqs into the review queue I am sure this question of why I am not
using mpl is going to come up and may cause the library to be blindly rejected,
so I am going to start fighting back now!

>    vector<int_<1>, int_<2> >
>
>    vector<integral_c<int,1>, integral_c<int,2> >
>
>    vector_c<int, 1, 2>
>
> are all different types, and they always will be.  There's nothing we
> can do about that, period.

That shouldnt stop discussion of whether it is the best design.

Arranging it so that you always get the
> exact type you expect would require a great deal more code than we're
> using now, and may not even be possible.

I shall continue to question whether it is the best design. I dont know whether
there are plans to C++ standardise any of mpl , but I would certainly like to
raise that and some other issues in that case.

regards
Andy Little