Jens wrote:
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.
Yes. But there are two existing ways for the user to say what they mean: (1) By using int8_t / uint8_t for number-bytes and char for character-bytes. For this to work we would need to either (a) Do some magic so we can distinguish [un]signed char from [u]int8_t. I believe that's impossible. (a) Change the behaviour of standard streams for [un]signed char. That's not going to happen, and even if it could happen it would probably break significant amounts of code that uses 'unsigned char' for characters. (b) Change lexical_cast to special case 'unsigned char' and 'signed char'. This is clearly unpopular with the list though I personally would be happy with it. (c) Allow the user to enable (b) if that is what they want. I get the impression that this could be done by supplying your own partial specialisation of lexical_cast; is this true? (Off topic, there is the question of whether common lexical casts can be made more efficient by providing specialisations that invoke C library functions like strtol(); I think someone told me that this wasn't possible, but I don't think I ever knew why.) (2) By using format() instead of lexical_cast(). (For to-string conversions. In principle something symmetric could be provided for from-string conversions.) Using format, you supply a format specifier in the style of printf() that indicates whether you want to do a string or numeric conversion. However, *this format specifier is ignored* and if you ask for a '%d' int8_t you'll still get a character. I would much prefer to have one of these existing methods 'do what I want', rather than invent something else. I'm going to see if I can write a my_lexical_cast() that uses lexical_cast by default but changes the behaviour for [un]signed char. Phil.