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

From: Jens Finkhäuser (jens_at_[hidden])
Date: 2007-05-09 14:20:06

On Wed, May 09, 2007 at 02:52:27PM -0300, Felipe Magno de Almeida wrote:
> On 5/9/07, Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:
> > Jody Hagins wrote:
> >
> > > However, char, signed char, and unsigned char are different types.
> > > int8_t is supposed to be typedef'd as signed char, which is a different
> > > type than char.  I do not see any reason lexical_cast<int8_t>() or
> > > lexical_cast<signed char>() should be treated the same way as
> > > lexical_cast<char> since the internal C++ type mechanisms treat "char"
> > > "signed char" and "unsigned char" as completely different types...
> >
> > Quite an interesting idea.
> > So 'char' would be a character, but 'signed char' and 'unsigned char'
> > would be integers.
> >
> > This behaviour might break some code, but I don't think 'signed char' or
> > 'unsigned char' are much used to store characters.
> 
> unsigned char are very used for type punning. IIRC, the only standard
> way to do that. So, unsigned char is used at least to hold "bytes",
> not only numbers.

  IMHO what this discussion shows is that in this case there's no
"obvious" meaning of 8 bit integer types (uses seem to be number,
character or byte). As far as I am concerned, that implies that it's up
to the user to supply that meaning, and not for the library to assign
one.

  Much as I like lexical_cast, in the light of this discussion, would it
not make a little more sense to be more explicit about what exactly you
want to happen? "Lexical" meanings aren't always obvious. How about
having
  string_cast<std::string>(123);
  int_cast<uint64_t>("127");
  int_cast<char>("127");
  string_cast<char>("127");
  float_cast<double>("3.1416");

  ... etc instead? The nice thing about those would be that they're
specializations of lexical_cast - you explicitly provide the information
on how lexical_cast should interpret it's type argument, in broad
classes of (more or less) built-in types: integers, floating point
numbers and character strings. For all types not falling into those
classes, stick to lexical_cast and whatever that brings.

  I have to admit that at this moment I can't recall much about the
implementation of lexical cast except that it uses string streams in
some cases, so this might not work without breaking more. But personally
I'm more in favour of providing more explicit types of casts than
deciding for the users of the library how to interpret what type of
char.