Re: [lmi] Stream cast problems with trailing spaces and more

[Greg Chicares]

On 2020-01-30 21:37, Vadim Zeitlin wrote:
> On Wed, 29 Jan 2020 23:02:34 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2020-01-29 16:45, Greg Chicares wrote:
[...]
> GC> In "INF", the characters 'I' and 'N'...
> GC> 
> GC>   https://cplusplus.github.io/LWG/lwg-active.html#2381
> GC> | are correctly parsed by std::strtod, but not by the stream extraction 
> operators
> GC> 
> GC> ...which could explain the outcome you report with clang and msvc,
[...]
> GC> if they haven't implemented the "proposed resolution".
> 
>  This is veering off-topic, but I'm not sure if the proposed resolution
> changes anything concerning "inf". It seems to only address the hex
> floating point numbers, i.e. it adds "p" and "P" to the list of accepted
> characters, but not "i", or "n", nor "f".

This is, sadly, correct. I did read the whole thing, but then I
disregarded the details that conflict with the prefatory principle:

https://cplusplus.github.io/LWG/lwg-active.html#2381

| If we're going to say that we're converting by the rules of strtold,
| then we should accept all the things that strtold accepts.

When they begin by enunciating such a general principle, I expect
them to honor it. The "proposed resolution" actually is a proposal,
but is not actually a resolution.

Suppose I order an "impossible" vegan burger without onions,
but they give me a chicken sandwich with onions, so I send it back
on the general principle that a restaurant should deliver exactly
what the customer orders...

| [2016-04, Issues Telecon]
| People are much more interested in round-tripping hex floats than
| handling inf and nan.

...and they send back a vegan burger (right) with onions (wrong),
because they deem that customers are much more interested in avoiding
meat than in avoiding onions.

>  However it still leaves the other failure, which is the exception when
> converting double to string in assay_speed(). The reason for it is also
> clear now and is in the line
> 
>     else if(!(interpreter >> std::ws).eof())
> 
> As there is no whitespace to extract, this causes failbit to be set. eofbit
> is set too, so the error here is not triggered, but the check for
> 
>     if(!interpreter || !interpreter.eof())
> 
> below is true because "!interpreter" is equivalent to checking for failbit
> which is set.
I've just pushed what I believe to be a full resolution.