"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