On Wednesday 13 November 2002 14:39, Fernando Cacciola wrote: > Unfortunately, some compilers -like bcc55- provide a 'default' > numeric_limits<> with no compile-time constants, while the specializations > do have compile-time values. Therefore, boost's numeric_limits<> is not > picked up for these compilers; but trying to use numeric_limits<> with user > defined types fails to compile unless the types explicitly specialize it > properly. > > I see three possible solutions here: > > (1) REQUIRE user defined types to *properly* specialize numeric_limits. > (2) Enhance boost/limits.hpp so that it 'fixes' only the default > numeric_limits<> if only that one is broken. > (3) Define my own user specializable traits. > > (3) is IMO a very bad idea since we would end up with overlapping traits > and potential ODR violations. > (2) might be a better solution but requires further examination. > (1) is the easiest way to go from the library developer POV, but might > annoy users.
IIRC, the problem even arises when using std::complex< double > as argument to std::numeric_limits<>. On gcc 3.2 for instance, the epsilon() is defined to be (0,0) which is certainly not correct and even highly dangerous. toon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
