[boost] Re: lexical_cast fixes

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-03-14 06:30:53

In article <3E719D8A.4090303_at_[hidden]>, Thomas Witt
<witt_at_[hidden]> writes
>
>As said before I am not trying to block the lexical_cast update for 
>1_30_0. That's beyond my power anyway. I'll try to rephrase my criticism 
>to be a bit more constructive.

Thanks, much appreciated. I can't do a lot with "the documentation needs
fixing" :-(

>All quotations from the current documentation.
>
>In general I do think a paragraph describing the changes in semantics 
>with respect to the prior version is missing. To me this is a must. IIUC 
>there are wchar_t support aside two significant changes in semantics. 
>First conversions to std::basic_string and second precision of floating 
>point output. The change in floating point precision handling might be 
>surprising to some users. Especially to those who use lexical_cast for 
>output formatting.

I will provide a changes section.

>In detail:
>
>"Returns the result of streaming arg into a std::stringstream  and then 
>out as a Target object".
>
>IIUC this is false for conversions to std::basic_string. If I read the 
>code correctly std::getline is used to extract the string from the 
>stream. There is a big semantic difference to using operator>> as 
>implied by the above sentence. 

Yes, this is legacy documentation. I went through and removed all the
obvious stuff, but missing is an updated note on the streaming
semantics.

>BTW why isn't streamobject.str() used to 
>extract the string? I do think this needs to be documented and a 
>rationale describing why the current semantics were choosen would be 
>really helpfull in understanding lexical_cast and the involved problems.

Two things:

(1) I would not consider that to be something to document as the
implementation should be free to choose a suitable approach, so long as
it satisfies the principle of least astonishment (the whitespace bug
clearly failed this test :->).

(2) Thanks for spotting a complete thinko and what nobody else noticed!
The whole point of the design was to allow stream.str() to be used,
hence the #ifdef call to stream.freeze(false) in the destructor.
However, I was looking after my son briefly between writing the
destructor and the string extraction operator. I guess I must have
spaced completely and just hacked out the getline solution without
thinking (... which is itself a feat, given the subtleties of I/O
streams...) when I sat back down.

So I will do better than provide a rationale, I will provide a code fix.

>"Note that spaces are significant in any conversion and are not skipped."
>
>I think this sentence was the main reason why I got the impression that 
>you didn't change the documentation at all. To me it is easily 
>misunderstood for someone who is aware of the problems with string 
>streaming. To me this sentence implies that
>
>lexical_cast<string>("U U");
>
>does not work. I.e. whitespace is significant.

OK, if you perceive ambiguity, those words needs changing.

Thanks, Kevlin.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________