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)