|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-04-19 03:55:53
In article <200304181851.37221.ghost_at_[hidden]>, Vladimir Prus
<ghost_at_[hidden]> writes
>
>I've just updated my project to use boost 1.30 and also gcc 3.2 and see
>exception which reads:
>
> bad lexical cast: source type value could not be interpreted as target,
> Target=i, Source=Ss
>
>The simple reproduction recipe is:
>
> #include <boost/lexical_cast.hpp>
> #include <string>
>
> int main()
> {
> boost::lexical_cast<int>(std::string(" 0"));
> }
>
>Note the space in string. The exception does not occur with gcc 2.95, but only
>with 3.2. I wonder if this should/can be fixed? Personally, I'd expect this
>code to work.
This is a gcc 2.95, errm, 'feature' :-> The code should not work, and
the behaviour with 3.2 is correct. It all depends on your expectation,
but according to the principle of least astonishment lexical_cast<int>("
0") should have the same success as lexical_cast<int>("0 "), which
fails. If you want leading and trailing whitespace to be removed, remove
them.
>And a related note: the exception's what() above is not quite helpfull.
Ah, yes, the ever descriptive gcc typeid names :->
>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.
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
mailto:kevlin_at_[hidden] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk