Besides this issue, AFAIK these are already usable. Of course, if you would like to improve them/contribute more optimal/clean/better in any other regard implementation, please do.
No, please go ahead! Cavalry have enough on their plates already (among other things, a new version of the library is upcoming, with plenty of new exciting and useful stuff like associative sequences), so progress on these two is totally in your hands.
-- Aleksey Gurtovoy MetaCommunications Engineering
Okay, I decided before I continue with my other library, I'll fully implement rational_c properly (and possibly fixed_c), however, doing so without making the code horribly complex would require changes to the current definitions of pretty much all of the operations (plus, multiplies, etc. as well as the conditional operators). The problem is that those current functions take 5 parameters, making specialization nearly impossible for the rational and fixed templates as you'd have to account for when the 3rd, 4th, 5th, etc parameters are not passed (and so the default integral 0 is used). That can't be easily done (at least I don't see how) without having to specialize each condition separately (one for 3 rational types, one for 4 rational types, etc ). Moreso, this applies to the conditional operators as well, there is no easy way to account for using different types in multiplies IE multiplying a rational and integral together, or a fixed and rational, etc. Again, to account for these possibilities you'd have to make an incredibly large amount of specializations. Of course, you could always just limit them to only work when all the parameters are the same kind of compile-time value template, but that would be somewhat limitting,especially with other solutions available. What I propose is a way around this situation, but still have the metafunctions declared the same way, therefore not breaking old code and not limiting functionality. To do so, the following adjustments would have to be made (and I have already begun to make them for my own use): 1) Additional versions of all of the arithmetic operators which take 2 parameters, each need to be defined and work like binary operators. They should be specialized for when both the left and right operands are of the same type. How to account for when they are different types will be covered in the future points. 2) A value_cast metafunction which can cast between all different compile-time constant types. The way it is implemented is by requiring all types to have specialized metafunctions for converting to and from the fixed point type. When value_cast is used, it, by default, converts the right hand operand to fixed_c, then converts that fixed_c to the target type. Since a fixed_c can hold pretty much any real value to a certain precision, you can be certain, to an extent, that little, if any precision will be lost through conversion. So, with that proposed addition, you'd be able to convert between all different types and only require people developing new types to have to specialize conversion to and from fixed_c. The only problem is that in order for the value_cast to exist, it obviously needs to have a parameter which specifies a type to convert to. The only way I can currently see that would allow that would be to have the value_cast take a type parameter which would be a template instantiation with a dummy value, which would, in a way, be very similar to rebinding allocators. 3) The conditional operations and 2 operand arithmetic operations should be redefined in the base template definition to convert both types to fixed_c and then make a comaprison, therefore allowing programmers to use the operations on two different types of compile-time constants without having to manually convert them to similar types before-hand (as I alluded in first point). The conditional operations can then be specialized for when the types are the same on each side to avoid the cost of a cast on each of the operands to fixed_c. 4) The current "varying length" operations which cause problems (multiplies, plus, minus, etc) should be redefined to just call the 2 operand version of the corresponding operation on each of the parameters passed to the operation. This way, programmers can still pass multiple parameters to these functions, with each parameter being a different type, without the developer having to make an extremely large amount of specializations for each type (including those which have yet to be developed). I have already begun implementing all of the points I have suggested, though with my rational_c as a the basis for conversion rather than fixed_c (as I haven't yet developed fixed_c). Also, converting to and from rational_c is considerably simpler than converting to and from fixed_c. For this reason, I may end up leaving the basis for conversion as rational_c instead of fixed_c. If anyone sees any other, more elegant solutions for the problems I mentioned, please post them and I may change my approach. Additional suggestions are also greatly appreciated. Thanks. -Matt Calabrese