[boost] mpl and pqs (physical quantities library)

From: Andy Little (andy_at_[hidden])
Date: 2006-01-08 15:10:19

Hi,

    Having now spent some time porting my pqs library

http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html

 over to boost, I am currently of the opinion that using mpl is not really
practical for use with the pqs library.

The main issue is  regarding the large amount of types created behind the scenes
by the mpl library. This is not acceptable in pqs  because pqs uses a large
number of parameters per quantity. The VC7.1 compiler is now frequently coming
up with an fatal error  message 'out of keys' during compilation of tests. For
comparison this wasnt a noiceable problem in the non-boost version   Obviously
for the library to be remotely useable I need to be as sparing as possible with
compiler resouces, allowing the user as much  room to work as possible.

In order for the pqs  library to be practical I need to use a family of types
for the dimension parameters that is designed with great care with respect to
the total number of types created behind the scenes. Even then I need to
acknowledge the issue of use of compiler resources by the library in the
documentation.

An example niggle regarding the mpl arithmetic operations , that they each use 5
parameters for e.g. addition  whereas minimally only 2 are required. This also
adds to the bloat for example. This is a particlar problem in the pqs library.

Another issue with mpl concerns the fact that mpl doesnt deal in types. This is
a problem when trying to register types  in conjunction with BoostTypeof . ..
What types to register ? (This is only a problem  because the lack of an inbuilt
typeof operator in C++).

I'll certainly leave the current version of boost::pqs around (pqs_3_0_1 now in
the vault in Physical Quantities Units directory) . I am aware that the
situation could be improved slighltly for example by not allowing conversions
from rational types to integral types, though the problem would still remain in
lesser form) I hope that pqs-3-0-1 will answer the question why I have opted not
to use mpl in the implementation in the next version.

regards
Andy Little