Re: [boost] Can type_traits be user specialized?

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
type
> > represents either integer or floating point values.
> > Can I use type_traits is_integral<> (or is_float<>)? That is, is the
user
> > 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
want
> 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
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm
>
Thanks, that's what I thought.

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.

What's your advise?

TIA,

Fernando Cacciola