"Cromwell Enage" wrote
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>
The convention of headers used with integral_constants is already invalid because of the use of the mpl::math namespace, therefore I dont see using a different design as a problem.
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.
Once the convention of each boost::math's types files having its own directory is set I would be quite happy with: #include <boost/mpl/math/rational.hpp> #include <boost/mpl/math/rational_/plus.hpp> BTW What is the purpose of '_' suffix. on the directory name?
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.
As stated above, just tell the user to get used to the convention of #include <boost/mpl/math/rational_/plus.hpp>
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.
Ok... Apologies to Peder Holt for misattribuing it. [..]
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.
In pqs the typeof interface is comprised of a limited number of types and certainly not mpl operations . I would expect to have the granularity primarily at the level of each type in the librarys interface. That means a separate register_X_with_typeof.hpp header for each type. The messy problem of exactly what type to register in mpl I now think needs to be left to the user, because the mpl library author cant know how the user will use the library. BTW while on the issue of result type of operations The member ::type of rational being a simplified_rational sticks out as being really odd. and with no precedent in the integral_constants. As an example of how odd it strikes me ... If this logic was applied to intgral_constants then the result type of mpl::plus<int_<X>,int_<Y> > would be added_int<Z>. OTOH I would expect the format to be either something like: template <typename N, typename D> struct rational{ typedef N numerator; // available for reflection, but no operations on these here typedef D denominator; //... typedef rational type; // rational is a unary_metafunction }; // then use (tediously) template <typename Rational> struct simplify_rational{ typedef typename apply_simplification_impl<Rational>::type type; // type is a rational<X,Y> where eg '5' /'10' --> '1'./ '2 'etc }; IOW simplification should be an interface operation to simplify a rational rather than a distinct user type resulting from the operation. Or alternatively and more practical IMO because simplification is be required before and after any operation anyway (to prevent overflow) it would relieve the tedium to just do the simplification in place. template <typename N, typename D> struct rational{ impl: typedef detail::simplify_rational_impl<N,D> > impl; public: typedef typename impl::numerator numerator ; typedef typename impl::denominator denominator ; typedef rational<numerator, denominator> type ; // simplification in place }; IOW I dont see any advantage to making the member ::type of a rational other than a rational.
[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.
OK thanks for the tip. regards Andy Little