[boost] Re: lexical_cast problem

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-04-21 05:18:32

In article <b8013r$rli$1_at_[hidden]>, Vladimir Prus
<ghost_at_[hidden]> writes
>
>The principle of least astonishment can be applied in a different way. We
>all know that lexical cast uses streams, and 
>
>    stringstream ss(" 1 ");
>    int i;
>    ss >> i;
>    cout << i << "\n";
>
>certainly works. It's surprising that lexical_cast<int>(" 1 ") does not
>work.

This is argument by false analogy. If the above were to fail, eg "a" was
the initialiser, it won't throw an exception. Yes, there is an
underlying stringstream, but lexical_cast uses stringstream; it is not
stringstream. The current model ensures that, unlike I/O streams, input
and output are treated more symmetrically and various constraints, such
as the full conversion of a buffered representation, are strongly
enforced.

A quick inspection of its history reveals a move away from the looser
I/O stream model of conversion. The original design was softer and more
script-like in its tolerances, but the general needs that most users had
were stricter.

If you want the kind of behaviour described above, I suggest using --
wait for it -- std::stringstream, or writing a trim function that cuts
leading and trailing space characters.

The idea that lexical_cast embodies in its current form is that it
allows only the _full_ conversion of the Source's stream representation
to the Target type, ie all chars are significant.

>BTW, I cannot find the test case for trailing space in
>lexical_case_test.cpp, and... the following works with gcc 3.2:
>
>   int main()
>   {
>      std::cout << boost::lexical_cast<int>(std::string("0 ")) << "\n";
>   }
>
>Hmm ;-) 

Thanks for spotting this. That is missing, and the accommodation of that
behaviour is legacy -- it is incompatible with the idea that full
conversion only is supported, and the way that textual types are
handled.

>>>Is it
>>>possible to output the stringstream content (if source -> stringstream
>>>conversion was successfull?)
>> 
>> This is something that I toyed with a long time ago, but eventually
>> decided not to put in for a couple of reasons. One is the issue that the
>> exception would hold a dynamically allocated string of potentially
>> unbounded length, rather than just a short descriptive string. 
>> I was
>> also concerned that the role of such an exception was more as a
>> debugging tool than an exception handling medium.
>
>Alas, it's not very helpfull as a debugging tool as it is. 

No, and that's because it is not primarily intended to be a debugging
tool. The only resolution I can see that accommodates this in part,
without running foul of reasonable constraints on exception types, is to
use a fixed-size char array that truncates the residual buffer content
if necessary.

Kevlin
____________________________________________________________

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