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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-09 03:25:23

On 5/8/07, Gregory Dai <gregory.dai_at_[hidden]> wrote:
> On 5/8/07, Dan Day <coolmandan_at_[hidden]> wrote:
> >
> > On 5/8/07, Mathias Gaunard wrote:
> > >Dean Michael Berris wrote:
> > >> I still think the
> > >> semantics of `lexical_cast("127")` should allow for the
> > >> conversion to happen -- either convert to a 'short int' then assign to
> > >> a char, if that makes any sense.
> >
> > >There is no way to distinguish int8_t and char. They are both aliases to
> > >the same type.
> > >Welcome to the wonderful world of typedefs.
> >
> >
> > Maybe I'm just short-sighted, but it seems to me this really isn't a
> > problem. A lexical_cast conversion from char * -> char doesn't make much
> > practical sense in my mind except for grabbing the first character in the
>
>
> Agreed. This is the same behavior as the std::iostreams do, as had been
> pointed out by a number of people already. Let's leave it at that.
>

I don't see why we should leave it at that though.

Considering the semantics of using static_cast<char>(1) -- unless
there's something wrong with that statement inherently -- the casting
type shouldn't complain that "hey, you're trying to cast an int to a
character... this shouldn't work!" but obviously the user definitely
wants to do that otherwise the user would've done it another way.

> string, which can be done numerous other ways. AFAICS, lexical_cast could be
> > specialized for char * -> char for such conversions as the OP desires. To
> > me, that would be far more useful than the current behavior.
>
>
> Nope, it's tempting to do "nice" thing, but again let's leave it at that
> (see above), and close the subject.
>

If the argument is just because the standard streams treat it that
way, doesn't mean that we should stick to that when obviously a
lexical_cast<T> implies that you want to convert a string / const char
* to a numeric value of the type T.

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>) 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> who actually expect to have a string converted to a
numeric value of type T -- granted that T is a numeric type.

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]