Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-15 09:00:34


----- Original Message -----
From: "John Maddock" <jm_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Friday, November 15, 2002 8:40 AM
Subject: Re: [boost] Can type_traits be user specialized?

> > 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,

OK. I'll go for (1) then.

> 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 :-(
>
Hugh!
Is this fixed by "boost/limits.hpp"?

Anyway, in the worst case, I think it is always possible to fix
numeric_limits<Num> at the user side.

> John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm
>
>

Thanks.

Fernando Cacciola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk