|
Boost : |
From: Andy Little (andy_at_[hidden])
Date: 2005-12-30 13:58:07
"Cromwell Enage" wrote
> --- Andy Little wrote:
> is_positive<> is okay, as long as
> is_strictly_positive<> (which zero<> is not) goes with
> it. I'd like to know how your Physical Quantities
> library uses the other metafunctions, so I can see if
> there are more generic ways to facilitate such usage
> (e.g. for seamless interaction with double_c).
Unfortunately I have now come upon an intractable problem. In debug mode on
small examples I am getting
" fatal error C1067: compiler limit : debug information module size exceeded".
(compiles ok in release mode)
In other examples I am getting a 'fatal' compiler out of keys error message.
These, I presume, result from the large number of types being created by mpl
behind the scenes. Whatever.. It renders the library useless for any practical
use. Nevertheless I uploaded it to the vault as pqs_3_0_1 in Physical Quantities
Units directory. To see what I mean ... In libs/examples directory try
compiling "box_example.cpp" in debug mode and see if you get the same result.
OTOH If the result is different let me know too!
I can compare this with my previous non-boost pqs version ( where I never came
upon this problem). When compile succeeds, the boost version for the same
functionality takes about 5 times
as long (25 seconds to 5 for example). IOW the boost version is completely
impractical and far inferior to the non-boost version. I have to say that
unfortunately I think that boost::mpl::math::rational is contributing to this
problem. It is certainly much more heavyweight than the previous rational I
used. I guess its designed for use with the other heavyweight mpl::math types,
but unfortunately because the dimension of a physical_quantity needs to use 7
per quantity it really drags down the compile times. (mpl::transform is probably
another large factor, maybe Typeof and all the mpl::math registrations dont
help either) I dont actually see much of a way around this if I use mpl, [I
think I can reduce it somewhat by only using rationals and not converting maybe
( I will try this next)], but I think currently that this style is not well
suited for my physical quantities library, unfortunately, both because of the
long compile times and because the junk in the library seems to clog up the
compiler ,leaving no room for program material!
yours depressedly
Andy Little
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk