> I have a problem however, which I think it would be useful to discuss > generally. > > 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.
I don't actually think (2) is possible unfortunately, I would vote for (1), it would be a precondition of your code that std::numeric_limits was properly specialised, note however that there is at least one case (VC6 + STLport) where numeric_limits constants are not usable in integral constant expressions even for those templates that are specialised :-( John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost