On Tue, 1 Aug 2006 12:42:35 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:

I am strongly in favour of supporting 8.0 warning level 4.

Yes, the OP talked about 7.1 though.

It provides ***some*** useful warnings, as well as some less helpful ones.

Code that is warning free is a higher quality even if the warnings are supressed because it shows the issues have been considered.

Makes sense. Unfortunately in code targeted at so many compilers as boost code is filtering the necessary #pragmas gets quite annoying, besides decreasing readability (unless you filter on the whole source file, which decreases reliability). I'll have a look this morning and see if it also emits warning for constant if expressions etc (I'm pretty sure 7.1 does). But I guess this can't go in the 1.34 branch at this stage (not that I think we are close to release, but I don't want to further move away from it either) -- [ Gennaro Prota, C++ developer for hire ]

Hi Gennero ! An'n Middeweken 02 August 2006, 00:55 hett Gennaro Prota schreven:

The "fix" is in the head only. Shout out very very loud if you want it in the RC_1_34_0 branch too :-)

The "fix" is wrong. It broke the "else if" statemen at line 150 and my gcc (4.0.2-SuSE) complains about "boost/lexical_cast.hpp:150: warning: statement has no effect". I propose the following patch. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de

On Wed, 2 Aug 2006 14:11:20 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:

But this is STILL the WRONG formula for the number of digits!

It should be max_digits10.

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

PLEASE can we get at long last get this right so that floats can be serialized without losing a few bits.

I presume lexical_cast will be totally rewritten not too far in the future, to optimize some specific conversions, as also recently discussed. That's why I've tended to postpone issues about it. But if you really feel strongly about this specific problem (please, say "I do so swear" ;-)) I'll give it a thought. But...: are you serializing floating point values by means of lexical_cast? -- [ Gennaro Prota, C++ developer for hire ]

On Wed, 2 Aug 2006 20:35:19 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:

| But...: are you serializing floating point values by means of | lexical_cast?

No - I meant 'stringizing'

Ok. It seems to me we need something along these lines (off the top of my head): #include "boost/limits.hpp" #define BOOST_is_ieee754(t) \ typedef char required [ \ std::numeric_limits<t>::is_iec559? 1 : -1 \ ] /**/ template <typename T> struct digits2 { enum { value = std::numeric_limits<T>::digits }; }; template <typename T> struct min_digits_10 { BOOST_is_ieee754(T); enum { value = 30103 * (digits2<T>::value - 1) / 100000 }; }; template <typename T> struct max_digits_10 { BOOST_is_ieee754(T); enum { value = 2 + 30103 * digits2<T>::value / 100000 }; } #undef BOOST_is_ieee754 -- [ Gennaro Prota, C++ developer for hire ]

On Thu, 3 Aug 2006 12:29:34 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:

| >No - I meant 'stringizing' | | Ok. It seems to me we need something along these lines (off | the top of my head): | | #include "boost/limits.hpp" | | #define BOOST_is_ieee754(t) \ | typedef char required [ \ | std::numeric_limits<t>::is_iec559? 1 : -1 \ | ] /**/

This was important; see below.

This seems overcomplicated to me.

Uh? Ok, I started with the idea to not use numeric_limits<>, then used it :-) But I typed directly in the newsreader window so I'm forgiven (by myself :-P)

the guaranteed 'minimum' digits are already defined by numeric_limits<>::digits10() (for float 6)

Ok.

and the next version of C++ will provide numeric_limits<>::max_digits10() (for float 9)

I know. One point I'm not sure about, though: is it the intent for it to be defined (and != 0) for non IEEE 754 implementations too?

so all we need to do is to use the

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

Does that work for non IEEE 754 floating points too? I guess not. And in that case we have to check. There were two other points addresses by my code: single templates (or metafunctions) are largely preferable to the single monolithic numeric_limits (especially in boost, where including "boost/limits" will likely bring the world into your translation unit). That's, I guess, the position of most boosters. Secondly, static const data members of integral types (see also core issue 454) easily lead to ODR violations, with no diagnostic required. I'm eagerly waiting for strongly typed enums to solve that problem. The issue is: you can inadvertently bind the expression to a reference, for instance by using a vector<>::push_back, and nobody will provide a definition for you. Enums do not have such lvalue complications. I'd like that the declaration of static const ints members be made a definition (I believe modern linkers can manage that) but who knows... will that ever happen? (Probably obvious answer here) -- [ Gennaro Prota, C++ developer for hire ]

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov | Sent: 03 August 2006 19:53 | To: boost@lists.boost.org | Subject: Re: [boost] Spurious warning in lexical_cast.hpp | | Gennaro Prota wrote: | > On Wed, 2 Aug 2006 14:11:20 +0100, "Paul A Bristow" | > <pbristow@hetp.u-net.com> wrote: | > | > >But this is STILL the WRONG formula for the number of digits! | > > | > >It should be max_digits10. | > > | > >stream.precision(2 + std::numeric_limits<Source>::digits | * 301/1000); | > > | > >PLEASE can we get at long last get this right so that | floats can be | > >serialized without losing a few bits. | | I have not get a chance to study the subject yet but I | wonder why don't | you just set a precision to some huge number, say 32767 or INT_MAX? This would be hugely wasteful as it would convert everything with 32767 decimal digits, of which, even with 256-bit floating point, 32267 digits would be noise! And in rely to Gennaro's question, | stream.precision(2 + std::numeric_limits<Source>::digits * 301/1000); | Does that work for non IEEE 754 floating points too? | I guess not. And in that case we have to check. It should be as good as you can get - certainly MUCH better than just using the default of 6 decimal digits. This is because numeric_limits<>::digits is the precision of the significand in bits, and the formula divides by log2 ~= 3 to convert binary to decimal and adds 2 to make sure there are enough to ensure a 1 least significant bit change shows up. For example, it works well with NTL quad-type (also used with Darwin long double) which is not an IEEE754 type. And it is used with Boost.Test and works fine with quad_float. But one of the reasons for introducing numeric_limits<>::max_digits10 (apart from making it easy and efficient for ordinary users) is to allow specialisation of this value to suit user defined types. For example, with arbitrary precision types, one could tie it to the precision you have chosen, say 100 decimal digits with NTL RR type or the current length an exact real type. Sadly AKAIK, we can't just add max_digits10 to numerical_limits now - we have to wait until the standard is accepted by library suppliers. So lexical_cast will have to have another upgtrade later, but meanwhile we should using this formula, perhaps internally defining a private max_digits10 to ease this change later. We certainly need a TODO comment. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota | Sent: 04 August 2006 13:14 | To: boost@lists.boost.org | Subject: Re: [boost] Spurious warning in lexical_cast.hpp | | On Fri, 4 Aug 2006 12:16:03 +0100, "Paul A Bristow" | <pbristow@hetp.u-net.com> wrote: | | >And in rely to Gennaro's question, | > | >| stream.precision(2 + std::numeric_limits<Source>::digits | * 301/1000); | > | >| Does that work for non IEEE 754 floating points too? | My question was just if it (the formula) requires IEEE754 or not. IMO, it does NOT require IEEE754 - it only requires numeric_limits<T>::digits to be correct for that type T. So, it works for NTL quad_float which is NOT IEEE754. | As to the docs, this is what I would add. Feedback welcome. | | lexical_cast<> offers the following guarantees: | | - in the absence of overflow/underflow, | | * if a "decimal string" with at most numeric_limits<T>::digits10 | significant digits is converted to a floating type T and back | to a string the result will equal the original string value. | | * if a floating point value having type F is converted to a | string allowing at least max_digits10 [or our formula here] | significant decimal digits and back to F the result will | be the original number. Well in principle yes, but the C++ Standard is not clear if the second is REQUIRED, or is just a Good Quality Implementation. At present, I only know for certain that MSVC 8.0 (and earlier?) does not QUITE achieve this - there is a tiny range of double (and of course long double which are the same) values for which one third of values are one bit wrong. (For float it is true). When I reported this as a bug, it was deemed a feature, but I would not be surprised to see it fixed, since a similar problem existed for float and was also deemed a fixture, but was fixed at 8.0. So sadly, it is a desirata not a guarantee :-(( Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Joh Maddock tells me you are concerned that the maxdigits_10 magic formula doesn't work with base other than 2. This is obviously entirely true, but decimal based C++ as rare as hens teeth? So it is seems hardly worth an extra test of numeric_limits<>::radix in every invocation of lexical_cast that I fear cannot be optimised away until C++0X hits the streets (and can be relied upon in every compiler). (Unless if can be done with a macro - but then there is a problem with it being standard). So I'd leave a comment, and put the problem in the 'too difficult' drawer for now? Thanks for your work on this nonetheless. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota | Sent: 04 August 2006 18:40 | To: boost@lists.boost.org | Subject: Re: [boost] Spurious warning in lexical_cast.hpp | | On Fri, 4 Aug 2006 14:33:30 +0100, "Paul A Bristow" | <pbristow@hetp.u-net.com> wrote: | | >IMO, it does NOT require IEEE754 - it only requires | >numeric_limits<T>::digits to be correct for that type T. | > | >So, it works for NTL quad_float which is NOT IEEE754. | | That's what I was wishing to hear :-) | | >| As to the docs, this is what I would add. Feedback welcome. | >| | >| lexical_cast<> offers the following guarantees: [...] | >| | >Well in principle yes, but the C++ Standard is not clear if | the second is | >REQUIRED, or is just a Good Quality Implementation. | | Hmm... what about "lexical_cast<> requires a good quality | implementation"? ;-) Seriously, I'll take some time for writing good | unit tests, so that we can have a clear view of what happens. | | This looks like a very sound addition to me. If it proves so in | practice I guess Beman can add it to the standard proposal. | | -- | [ Gennaro Prota, C++ developer for hire ] | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |

Hi Gennaro ! An'n Middeweken 02 August 2006, 17:36 hett Gennaro Prota schreven:

On Wed, 2 Aug 2006 09:02:57 +0200, Jürgen Hunold <hunold@ivembh.de>

...

The "fix" is wrong.

I agree that it is not a "fix", FWIW. Just a change. But would you care explaining why it's "wrong"?

I wrote:

It broke the "else if" statement at line 150 and my gcc (4.0.2-SuSE) complains about "boost/lexical_cast.hpp:150: warning: statement has no effect".

This is ---begin cut else ((s::is_specialized) && stream.precision(s::digits10 + 1)); ----end cut and this should IMHO read: else if (s::is_specialized) stream.precision(s::digits10 + 1)); (see my patch...) This is clearer and prevents a warning from gcc... might be this will issue a warning from msvc-8.0... This if obviously a case where "fixing" one warning introduces another. I try to test those changes with at least one other compiler... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de