In article <[EMAIL PROTECTED]>, Vladimir Prus
<[EMAIL PROTECTED]> 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: +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
