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

[Vadim Zeitlin]

On Fri, 31 Jan 2020 16:30:20 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2020-01-30 21:37, Vadim Zeitlin wrote:
GC> > On Wed, 29 Jan 2020 23:02:34 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2020-01-29 16:45, Greg Chicares wrote:
GC> [...]
GC> > GC> In "INF", the characters 'I' and 'N'...
GC> > GC> 
GC> > GC>   https://cplusplus.github.io/LWG/lwg-active.html#2381
GC> > GC> | are correctly parsed by std::strtod, but not by the stream 
extraction operators
GC> > GC> 
GC> > GC> ...which could explain the outcome you report with clang and msvc,
GC> [...]
GC> > GC> if they haven't implemented the "proposed resolution".
GC> > 
GC> >  This is veering off-topic, but I'm not sure if the proposed resolution
GC> > changes anything concerning "inf". It seems to only address the hex
GC> > floating point numbers, i.e. it adds "p" and "P" to the list of accepted
GC> > characters, but not "i", or "n", nor "f".
GC> 
GC> This is, sadly, correct. I did read the whole thing, but then I
GC> disregarded the details that conflict with the prefatory principle:
GC> 
GC> https://cplusplus.github.io/LWG/lwg-active.html#2381
GC> 
GC> | If we're going to say that we're converting by the rules of strtold,
GC> | then we should accept all the things that strtold accepts.
GC> 
GC> When they begin by enunciating such a general principle, I expect
GC> them to honor it. The "proposed resolution" actually is a proposal,
GC> but is not actually a resolution.

 Yes, I was unpleasantly surprised by this as well. I would have preferred
an actual resolution.

GC> I've just pushed what I believe to be a full resolution.

 Thanks, I can confirm that the new unit test now passes with both clang
and MSVC.

 If you're not completely tired of this topic just yet, I have just one
last minor remark to make: IMO, "ostream inserter" and "istream extractor"
are really not that clear neither, even for the programmers, let alone for
the mere users. I'd rather use "formatting input value" and "parsing as
output value" or something similar, as IMHO it's easier to understand.

 But, again, this is just a nitpick, thanks for fixing the actual problem!
VZ

pgpMTFYcA5bPf.pgp
Description: PGP signature