Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-09 14:40:26


Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> Dave, I have shortened the subject since it seemed, so far, to be
> changed at each post preventing grouping the messages 'by thread' (at
> least with my reader). Now, it should have been changed once for all.
>
> On Thu, 09 Jan 2003 13:21:12 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>
>>Uh, wait a sec. Is it a good idea to mess with
>>boost/detail/limits.hpp?
>
> Gulp! I thought I was proposing "simplifying" it, not messing! :-)
>
>>It's just a workaround for broken/missing
>>numeric_limits implementations, and it was a pain to get right. Did
>>you mention this before? If so, I guess I missed it.
>
> No, I didn't mention it. As I said, I never saw the code before.
> Anyway it seems simply copied by some SGI implementation, so I doubt
> it was such a pain to get right (no offense intended, really)

Before you say that, look at the CVS revision history.

>>> BOOST_STATIC_CONSTANT(int, digits, precision<T>::value);
>>
>>I guess if you think it's doing something wrong and you can fix it,
>>it's worth doing.
>
> It depends on what you mean by "wrong". It works on all the compilers
> supported by boost but is uselessly complicated and not portable.

OK, if it works I'm for it.

>>> Note, as to digits and digits10, that a similar clean up is
>>> possible for floating point types too, by adding e.g.:
>>>
>>>
>>> template <typename T> struct digits {
>>> BOOST_STATIC_CONSTANT(int, value = 0); // dummy value;
>>> (debatable)
>>> };
>>>
>>> template <> struct digits<float>
>>> { BOOST_STATIC_CONSTANT(int, value = FLT_MANT_DIG); };
>>> template <> struct digits<double>
>>> { BOOST_STATIC_CONSTANT(int, value = DBL_MANT_DIG); };
>>> template <> struct digits<long double>
>>> { BOOST_STATIC_CONSTANT(int, value = LDBL_MANT_DIG);};
>>
>>Not sure if this will work portably.
>
> Do you mean that we have implementations that don't provide the
> x_MANT_DIG macros? Otherwise the code is perfectly portable by
> 18.2.1.2 of the standard.

No, I mean that those specializations might not be portable to all
compilers. Remember that this file is for broken implementations to
begin with.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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