Re: [boost] [MPL.Math] Updated version now available

From: Andy Little (andy_at_[hidden])
Date: 2006-01-15 06:51:50

"Cromwell Enage" wrote

> Try to eliminate the use of mpl::vector first, since
> it's the biggest slowdown for you.  See if you can
> replace it with Boost.Preprocessor constructs.  This
> method worked well for me when I gave big_integral an
> overhaul.

Unfortunately  if I use mpl::rational then I  need to use mpl::equal_to for
comparison. The 'dimension' of a physical_quantity is made of rationals so I now
have to use mpl::equal_to for comparison of those. Alternatively by defining my
own rational  I can use boost_is_same to compare dimensions. What this means is
that for any particular type I only have one possible pattern of parameters
matching a particular type. This both saves compiler resources and speeds up
compilation.  For this reason I have opted to remove use of mpl::rational as
well as mpl::vector from the next version of pqs.

I do question why  plus<int_<X>, int_<Y> > ::type is not guaranteed to be an
int_<Z> however. This is the source of the problems with my use of mpl I think.
This type of functionality is mentioned as surprising in
http://www.boost.org/libs/mpl/doc/tutorial/implementing.html
in relation to vector_c , but the principle issue is the same. If mpl were to be
standardised I would question whether this behaviour is the best one.

regards
Andy Little