Re: [boost] [lexical_cast] performace patch

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-07-07 04:40:38

I'm sure this will help some people.

It would be nice at the same time if you could ensure that lexical_cast
doesn't produce a blizzard of warnings if compiled in "strict" mode (MS
level 4).  Some people would like to use this option to check their own
code, but are deterred by the noise from lexical_cast.  This just needs some
pushing and popping of warning levels (or the re-writing of some ifs before
returns - the current code is correct but the compiler can't see that and so
issues a warning).

I also note that the expression for calculating the precision is STILL wrong
and will fail loopback tests, and especially annoying to serious with
serialisation.  I thought this had been corrected at 1.34.

It should be max_digits10.

stream.precision(2 + std::numeric_limits<Source>::digits * 301/1000);

http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf

If you are concerned with speed this could be replaced by a constant macro
when specialising double, float and long double for example.

#define FLT_MAXDIG10 (2+(FLT_MANT_DIG * 3010)/10000)
#define DBL_MAXDIG10 (2+ (DBL_MANT_DIG * 3010)/10000)
#define LDBL_MAXDIG10 (2+ (LDBL_MANT_DIG * 3010)/10000)
which yield the following values on typical implementations:
FLT_DIG 6, FLT_MAXDIG10 9
DBL_DIG 15, DBL_MAXDIG10 17
LDBL_DIG 19, LDBL_MAXDIG10 21

http://www2.open-std.org/JTC1/SC22/WG14/www/docs/n1151.pdf

Thanks

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]
  
|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Nasonov
|  Sent: 06 July 2006 19:57
|  To: Boost developers list
|  Subject: [boost] [lexical_cast] performace patch
|  
|  Hi,
|  I'm preparing a patch to improve a performance of lexical_cast
|  for certain combinations of types.
|  For example, int to char transformation is 5.9 times faster on
|  my FreeBSD. It could be even faster if not a requirement to add
|  a thousands separator.
|  
|  There are few issues I'd like to sort out before I finish the work.
|  
|  1. Enums, unlike integral types, are not optimized. I don't want
|     to break a conversion from enums with user-defined operator<<.
|     My firm opinion on this is not to support this edge case and
|     allow optimization.
|  
|  2. To improve a performance even further, I'd like to add
|     lexical_cast< boost::array<N,char> >(arg) but it would break
|     InputStreamable requirement.
|  
|  3. A couple of conversion functions are good candidates for 
|  .cpp file.
|     I expect a strong resistance to this change. Don't get me wrong,
|     I'm not going to change this in default build, I'm asking for new
|     configuration parameter. Something like BOOST_LINK_CORELIB.
|     A user should always link with -lboost_core if BOOST_LINK_CORELIB
|     is defined.
|  
|  That do you think?
|  
|  -- 
|  Alexander Nasonov
|  Project Manager at Akmosoft ( http://www.akmosoft.com )
|  Blog: http://nasonov.blogspot.com
|  Email: $(FirstName) dot $(LastName) at gmail dot com
|