Re: [boost] [HEAD] lexical_cast<int8_t>("127") bug?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-09 07:02:22

On 5/9/07, Mathias Gaunard <mathias.gaunard_at_[hidden]> 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
[phone]