"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. Isn't it normally beneficial to
--- Andy Little wrote: try to limit
per header dependencies? What is the rationale behind adding double and big_integral in there too?
It's an unfortunate artefact of the implementation. If I could write numeric_cast<double_c_tag,rational_tag> without using numerator<double_c_tag>, or write numerator<double_c_tag> without returning simplified_rational<big_integral...>, I would. In the meantime, the main problem we've run into here is one of granularity. With integral_c and friends, you can just #include <boost/mpl/integral_c.hpp> #include <boost/mpl/plus.hpp> ... typedef plus<integral_c<long,1>,integral_c<short,2>
three; Not so with these other numeric constants. You can't #include <boost/mpl/math/rational.hpp> #include <boost/mpl/plus.hpp> without #include <boost/mpl/math/rational_/plus.hpp> One of the two files must include this one. It's not going to be plus, so it has to be rational. Furthermore, for the moment, I can't be sure which operations will or will not be used...so I have to #include them all. To achieve the finer level of granularity you seek, then, I need a safe way to #include certain files if and only if other files are #included, e.g. #include <boost/mpl/math/rational.hpp> #include <boost/mpl/plus.hpp> implies #include <boost/mpl/math/rational_/plus.hpp> I'll look into it when I get the chance.
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.
It's not *my* double implementation, it's Peder Holt's, and the metadata are already stored int BOOST_STATIC_CONSTANTs.
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 don't need registration for the vast majority of these types, also bearing in mind that space in the Typeof vector is limited, so I don't think registering everything is a practical way to do it.
Okay.
It must be possible for me the user to be able to register each type separately (only if it becomes necessary). Of course the problem comes then because mpl works in terms of concepts rather than type-names, so I might get an int_, an integral_c, or a long_; a rational or a simplified_rational. I don't 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 don't think registering everything at one go is a good solution.
If you can ensure that the *only* syntax you use for any operation (numeric or otherwise) is typedef typename some_op<...>::type some_constant; and not typedef some_op<...> some_constant; then maybe #defining a macro BOOST_MPL_CFG_TYPEOF_NO_REGISTER_FUNCTIONS will suffice.
[snip future plans w/o MPL]
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. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com