Boost logo

Boost :

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

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

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

>>>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 Henney phone: +44 117 942 2990
  mailto:kevlin_at_[hidden] mobile: +44 7801 073 508 fax: +44 870 052 2289
  Curbralan: Consultancy + Training + Development + Review

Boost list run by bdawes at, gregod at, cpdaniel at, john at