[boost] Re: Complex type failure with boost::lexical_cast

From: Preston A. Elder (prez_at_[hidden])
Date: 2005-01-29 22:56:47

On Sat, 29 Jan 2005 23:53:45 +0100, Terje Slettebø wrote:

> "s" is used a couple of places in the code, where I assume "input" should be
> used instead (or it gives an error when compiling). Apart from that, I get
> the same result.
Uh, yeah, sorry, I was transcribing from my test application at the
same time (I didn't copy/paste it).

>> 2. lexical_cast ignores trailing whitespaces, but not leading
>> whitespaces. Meaning that
>>
>> int a = lexical_cast<int>("3 "); // three-space
>>
>> will work and return 3, but
>>
>> int a = lexical_cast<int>(" 3"); // space-three
>>
>> will throw. Why? There's no rationale here. Both cases should be treated
>> in the same manner, and IMHO, that manner should be throwing.
> 
> So what should lexical_cast do; strip or not? Ladies and gentlemen, can we
> have your votes? ;)

I am of the opinion we should follow the standard (ie. STL) in this one. 
The STL would accept both, and since we rely on operator>>, so should we. 
I mean, if you're going to be anal about spaces, be completely anal about
them, but I don't think we should be, I think accepting whitespace before
and after is correct, just as the stringstream operator>> does by default.

> Adding options to lexical_cast is difficult. It's meant to resemble regular
> casts, and any additional template- or function-arguments makes it no longer
> look like a cast.

Not really, make it a policy - defaulting to one or the other, eg:

myclass a = boost::lexical_cast<myclass>(s);    will not care about spaces.
myclass a = boost::lexical_cast<myclass, noskipws>(s);    will care.

Its easy enough to default the argument:
enum ws_policy { skipws, noskipws };
template<typename T, ws_policy wsp = skipws>
class lexical_cast { ... };

Or even better:
template<typename T, std::ios_base::fmtflags newflags =
         std::ios_base::skipws>
class lexical_cast { ... };

Then just do:
std::stringstream ss;
ss.flags(newflags);

And carry on about our merry way.  The latter way gives us great
flexibility - allowing us to control the IOS flags ourselves, while still
keeping a simple and backward compatible interface, and most importantly,
its dead easy to implement :)

> Good point. I've cc'ed this reply to Kevlin Henney, as I don't think he's
> subscribed to the list.
Thanks, if you could pass this one on too, please do :)

-- 
PreZ :)
Founder. The Neuromancy Society (http://www.neuromancy.net)