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

From: Andy Little (andy_at_[hidden])
Date: 2006-02-28 16:54:42

"David Abrahams" wrote
> "Andy Little"  writes:
>
>> "Andy Little"  wrote
>>
>>> The expectation ( based on OP's light reading of examples I guess ) is this
>>>
>>>   assert( boost::is_same <
>>>      mpl::transform<
>>>          vector_c<int,1,2,3> ,vector_c<int,1,1,1> ,some_plus_func
>>>      > ::type ,
>>>      vector_c<int,2,3,4>
>>>    >::value == true);
>>>
>>> Personally I think ( even ) that is with (some mods) a realistic
>>> expectation.
>>
>> FWIW Enclosed is a small sample which seems to work ok in VC7.1 and gcc4.01,
>> bearing in mind its based on expectations not status quo
>> Formatting of output works best in vc7.1 BTW.
>>
>> IOW Its not impossible to make it work.
>
> <sigh> Nobody ever said it was impossible.
>
> What you're doing here fails one of the primary design goals of the
> MPL: in the same way that the STL iterator abstraction avoids an MxN
> explosion of algorithm implementations (where M is the number of
> algorithms and N is the number of data structures), the MPL is
> designed to avoid the same kind of explosion.  If you follow this
> path, you will end up reimplementing every algorithm once for every
> data structure.
>
> Finally, even if you do meet the expectation, it will be incredibly
> fragile: it becomes impossible to extend the library (or user code)
> and continue to meet expectations.  You add a new algorithm, and then
> suddenly the expectation is broken for any user-defined sequence types
> that you didn't know about.  You add a new sequence, and the
> expectation is broken for any user-defined algorithms you didn't know
> about.
>
>> Might be useful as a relatively simple demo anyway. Could also be
>> used to explain the reasons for rejecting this approach too of
>> course ;-)
>
> I hope you find my explanation above satisfactory.

I understand it. I concede that I was wrong to argue about it, so I'm sorry for
wasting your and everyone elses time.

Of course If anyone can implement the dimensional-analysis part of pqs ( in the
Boost vault in The Physical Quantities Units directory) , such that
it compiles faster than it does currently, by using mpl, then I will  be happy
to re-implement it using mpl. Otherwise I dont currently see the benefit. That
may change of course if for some reason I need the mpl  features you mention
above, though currently the dimensional-analysis code seems quite stable. The
only reason I can see might be to make the sequence of base-units modifiable in
length, however my inclination would be to do this by means of a config macro .
Anyway I  shall be interested to see what Noel Belcourt comes up with.  My
feeling is that  mpl is unlikely to beat the current set up in terms of
compilation speed but I'd  be happy to be proved wrong. It is of course a very
unfair challenge because my code is customised for this one job , whereas mpl
must be generic.

regards
Andy Little