In article <[EMAIL PROTECTED]>, Thomas Witt
<[EMAIL PROTECTED]> 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: +44 117 942 2990
mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
____________________________________________________________
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
