Your example is interesting. I think that providing a Macro value allows this sort of UDT extensions code (very like Michael Kenniston's examples).
I fail to see how this should work. Could you elaborate a bit, please?
My thesis that 40 decimal digits are enough is because it is enough for all existing floating point hardware, up to 128 significands. I believe that anyone wanting more is likely to be using a separate 'unlimited' precision package anyway.
That exactly is my point: People will choose such a package, but how can it be glued by the user to boost's constants? And to the code the user already wrote? Taking into account that boost is intended to be some kind of pre-standard-library, I think we should allow the extension of constants to be used with new float-types. Using the constants in a generic way is only possible when we have a standardized way of accessing them. This is why I concentrated on allowing explicit casting and the direct use as in pi*(float)(...). I don't see how the user could use Roguewave's decimal type with Macros (or any other user defined float-like type. And I don't think that using such a library should result in a choice for the user to either use constants from boost with the according interface or hope for the vendor to specify the constants and use their interface.
There is also an example of a UDT _interval_ - a 128-bit quad_float type, used by Victor Shoup's NTL package. But it does require using the NTL generator program to create the exactly representable values. (See test_quad_float.cpp example). I believe that interval constants are an important feature - and quite novel.
I don't understand that example, sorry. Thus I also miss the importance of this feature. What exactly are interval constants? What problem are they addressing? Isn't it an orthogonal concept to constants like 'pi', 'e', ...? Should / could it be placed into a separate library (maybe on top of the basic constants library)? I also looked at other examples like test_pi_interval, but I still don't understand the idea that's behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and this is IMHO unacceptable for generic programming.
Regards, Daniel
PS: The toy-example I posted only worked for the GCC 3.x, but I extended it a bit to make it work with the Intel compiler and with older GCCs (2.95.x). If there is any interest, I can post it...
-- Daniel Frey
aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
