| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock | Sent: 11 February 2006 13:43 | To: boost@lists.boost.org | Subject: Re: [boost] Using BOOST_ASSERT to check | numeric_limits<FPT>::epsilon | | > epsilon should be a constant known at compile time? | > But is the compile unable to know this? | | Static assertions require an integral-constant expression, | and epsilon is | basically a runtime constant (at best it's a floating point constant). | | BTW I don't believe you can portably use DBL_EPSILON etc in a static | assertion: you certainly can't use the DBL_* macros in preprocessor | directives as I've found to my cost already. A vendor is entitled to | implement this as: | | #define DBL_EPSILON __dbl_eps | extern const double __dbl_eps; | | > Other suggestions on how to achieve a compile-time warning here? | | Not really, other than checking for numeric_limits<>::is_specialized. | | John. I feared as much. (In fact worse than I feared - you might like to add these to the static assert docs - I would have dropped into this trap :-(( ) Supplementary question: What impact will it each of the following have on Darwin long double (that I believe you have used) if fp comparisons includes: BOOST_STATIC_ASSERT(numeric_limits<FPT>::is_specialized); and BOOST_STATIC_ASSERT(numeric_limits<FPT>::is_iec559); and if (numeric_limits<FPT>::epsilon() <= (FPT)0) { // numeric_limits not correctly specilized! return false; // Better warning desirable. Throw? } We discussed numeric_limits<FPT>::epsilon() and I think we can produce an intuitively useful (if not exact) value using the normal formula 2^(1-significands) Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html