From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-04-10 08:13:06
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Maxim Yegorushkin
| Sent: 10 April 2006 09:31
| To: boost_at_[hidden]
| Subject: Re: [boost] Report from Berlin C++ Standards
| Committee meeting
| * Boost Lexical Cast has been tentatively accepted by the LWG for TR2.
| > This has to be one of the most useful utilities in Boost.
| All developers I know roll out their own versions of lexical_cast.
| Last time I checked the implementation of boost::lexical_cast it had
| efficiency bugs. There at least should be specializations for string
| -> integer/double conversions that use strtoul/d functions directly
| rather than iostreams.
Agree this would be nice, but it is also vital IMO that lexical_cast (and
serialization) should 'round-trip' correctly, as in recent discussion:
One the the requirements for 'round-tripping' is to get the number of digits
'written' right, and neither of these are correct at present.
I have tried to get acceptance for this trivial, but still very important
which has also just been accepted for inclusion in C++0x
static const int digits10 = 0;
static const int max_digits10 = 0;"
which would be used by writing:
However I do not see how to add these until the new numeric_limits
definition is available. (Will someone correct me if I am wrong about
ADDING to the existing definition)
and also, to be included in the next C Standard mailing
which proposed provision of macros for these values thus for the built-in
#define FLT_MAXDIG10 (2+(FLT_MANT_DIG * 30103UL)/100000UL)
#define DBL_MAXDIG10 (2+ (DBL_MANT_DIG * 30103UL)/100000UL)
#define LDBL_MAXDIG10 (2+ (LDBL_MANT_DIG * 30103UL)/100000UL)
Meanwhile, I am confident that the best formula to use is
2 + std::numeric_limits<FPType>::digits * 30103UL/100000UL;
and to use these in both in Boost lexical cast and serialization. and also
test (which does already use the correct number of digits, but might fail
for some higher precision types, as noted below).
(Note that the reason for using 30103UL/100000UL is avoid an inaccurate
result for higher precision types like 113 significand bits used by VAXH and
IEEE quadruple, and future 256-bit floating point. But this ratio, and
3010/10000, would cause overflow on 16-bit integer systems, so if
numeric_limits<int>::digits < 32 the ratio should be 301/1000. For this
observation I am indebted to the eagle-eyed Fred J. Tydeman.)
I am not clear if we need to worry about 16-bit integer systems - are any
toaster manufacturers whoch have not moved on the 32-bit processor planning
to use lexical_cast, serlialization or test? I am not sure if they will get
any warning of the overflow - I suspect not.
-- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow_at_[hidden] http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk