Cromwell Enage writes:
A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning.
Before I attempt to tackle this task anymore than I already have, I should have some questions answered.
1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression.
As Dave already replied, BOOST_NO_LIMITS has no bearing on it; it's simply not allowed.
Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input?
Yep, that's what it means.
Do I have to duplicate the functionality as a result?
Well, it's not really _duplicating_ of functionality; you have to implement the same set of primitives for a different representation, yes.
If so, what should be the naming convention for these new metafunctions?
I assume we are talking about arithmetic metafunctions in particular. Well, the ideal solution is outlined in http://article.gmane.org/gmane.comp.lib.boost.user/5668/, but for the purpose of implementing the functionality itself I suggest you abstract from all these complications and simply name these as you wish, e.g. 'fp_plus', 'fp_minus', etc., or anything along these lines.
2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this:
template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; };
If it gives us a satisfactionary range of representable values, sure.
3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how?
Within the wrapper struct, in form of a conversion operator, so we can write something like typedef float_<2,718281828> e; std::cout << e;
4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression?
As long as rational number representation gives us enough domain space, sure. -- Aleksey Gurtovoy MetaCommunications Engineering