"Cromwell Enage" wrote
I've added <boost/mpl/math/rational_/rational.hpp>, which contains the minimal amount you need to use only boost::mpl::integral_c et. al. and boost::mpl::math::rational. The <boost/mpl/math/rational.hpp> header is reserved for those who need the kitchen sink.
That seems like an odd way to do things. I would expect the main header for rational to just contain the interface for rational itself. Isnt it normally beneficial to try to limit per header dependencies? What is the rationale behind adding double and big_integral in there too? [...]
Anyway changing the gcd algorithm to a recursive one wrapping boost::math::static_gcd (attached) in "boost/math/commn_factor.hpp" cures the above problem of compiler running out of keys and similar issues for me.
I've reimplemented the integral_c_tag specialization of boost::mpl::math::gcd so that it's wrapped around an MPL-ized version of boost::math::static_gcd. Performance should be close to what you're looking for.
That looks a lot better. (Once I've waded through the macros). I'm not sure if you use rational with mpl integral constants in your double implementation, but if you do that mod should help compile times a there too.
As previously mentioned I also reckon that it would be best to make typeof registration separate.
I thought you said "optional". Anyway, typeof registration is now disabled by default; you must now define the macro BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to enable it.
For each type, typeof registration is quite a heavyweight process, so I want to only register those types that I Really need to. Currently this is not the case so I get for example mpl::math::zero, mpl::math::denominator, etc etc, etc, etc and the kitchen sink registered for me though I dont need registration for the vast majority of these types, also bearing in mind that space in the Typeof vector is limited, so I dont think registering everything is a practical way to do it. It must be possible for me the user to be able to register each type separately (only if it becomes necessary.) Of coures the problem comes then because mpl works in terms of concepts rather than type-names, so I might get a int_, a integral_c, or a long_. , a rational or a simplified_rational. I dont really know a clean solution to the problem of what to register if I use mpl, (maybe 'per concept registration would be OK) but I dont think registering everything at one go is a good solution. Throwing the baby out with the bathwater. Having come up against compile times/debris problems in mpl as applied specifically to the pqs library ( mostly due to mpl::vector), In pqs_3_0_1, as an alternative style to the mpl way, I am currently thinking in terms of how to use the minimum variety of types, parameters and functions etc. This line of thinking means for instance that I would have a (custom for the pqs library) rational<1,2> , note not rational_c<int,1,2> or rational<int_<1>,long_<2> >. and also no conversion via the tag system between rational and int_ for instance. I can use boost::is_same rather than mpl::equal_to for comparison, which represents another reduction in complexity as well as a reduction in potential number of types created automatically. Similarly result of an operation on two rationals will be a rational, so that I can use boost::is_same for comparison of types comprised of rationals, have a definite 'type' interface and a known documentable type as result of operations and reduce the number of types requiring Typeof registration. IOW I have decided to abandon use of mpl entirely in the next version of pqs library and see if that helps specifically with the compiler out of keys issue (which I am still getting currently when using headers with a lot of physical_quantity types) and the compile time issue. These are greater problems in pqs than some other uses of mpl because the idea is to be able to use these types to 'seamlessly' replace bult-in types such as double and int. That means absolutely minimal effect on compilation time and of course minimal use of compiler resources too. regards Andy Little