On 5/9/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
Dean Michael Berris wrote:
I particularly don't see why the constraint that the standard streams imposes in this case should affect the behavior and/or semantics of lexical_cast<T> -- because if I really for instance wanted to use a standard stream (which has completely different semantics from lexical_cast<T>)
How is it different semantically?
std::istringstream iss(some_string); char t; iss >> t; I expected a character, and got the first one. Compare this to: char c = lexical_cast<char>(some_string); Where I explicitly say "I want to lexical cast some_string and store the value into a character". If for some reason some_string is beyond the bounds of the "char" type, then I should get a bad_lexical_cast saying so.
then I would have used that. Being that lexical_cast<T> uses a standard stream underneath the hood should be an implementation detail, and should not concern the users of lexical_cast<T>
It is not an implementation detail. That's how you can overload it, making lexical_cast generic.
What I meant was, that lexical_cast<T> may choose to do something else entirely under the hood, just as long as the expectation is that it casts a string to a numeric type given by T. If it so happens that through some typedef (or even explicitly), a lexical_cast<char>(...) is requested, the behavior of lexical_cast should be consistent and treat "char" as an integral type. lexical_cast<T> can still be generic and fulfill the semantics of the intended usage, by specializing on cases where T is a given type which holds (or can hold) numeric values specifically in the case where T is a char/signed char/unsigned char or typedefs thereof. Or if implementing that specialization is an abominable idea (which I don't see why it should be), then we should at least make it fail -- and say that at compile time, you're trying to use lexical_cast<T> in a manner that's not defined/supported. Or a warning which says "trying to lexical cast to a char..." would make sense, if that's at all possible. If you also think documenting this issue will and should be enough, then that should be acceptable too. But we should at least do _something_ about it -- we at least owe it to the users who might run into the same trap. Or not. :-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459