From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-13 08:39:57
----- Original Message -----
From: "John Maddock" <jm_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, November 13, 2002 8:53 AM
Subject: Re: [boost] Can type_traits be user specialized?
> > Suppose I'm writing some generic piece of numeric code that can be
> > instantiated with a User Defined Type (UDT).
> > And further suppose that I need to detect whether the generic numeric
> > represents either integer or floating point values.
> > Can I use type_traits is_integral<> (or is_float<>)? That is, is the
> > allowed to provide her own specializations of this templates?
> > If not, how should I let the user tell whether her numeric UDT is
> > integer/float/signed/etc...?
> No, is_integer and is_float etc are for built-in types *only*. If you
> to detect UDT's that are pretending to be numbers, then you should use
> std::numeric_limits<>, and provide a specialisation for these if required.
> John Maddock
Thanks, that's what I thought.
I have a problem however, which I think it would be useful to discuss
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
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
What's your advise?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk