On Jul 5, 10:48 am, "Alf P. Steinbach" <al...@start.nowrote:
[...]
Quote:
Quote:
On the other hand, I think in theory, char could be signed 1's
complement, and assigning a negative 0 (0xFF) could force it to
possitive (which would mean that you could never get 0xFF by
assignment---but you could memcpy it in). I think: I'm too lazy
to verify in the standard, and of course, any implementation
that actually did this would break so much code as to be
unviable.
|
|
Quote:
In that case any implementation for 1's complement that used
1's complement also for signed 'char' would be unviable... :-)
|
As it happens, in the two implementations I'm aware of where
signed integers are not 2's complement, plain char is unsigned,
thus avoiding the problem. (If one of the goals of plain char
is to contain text characters, then it really should be unsigned
anyway. Historically, however, making char unsigned had a
non-negligible runtime cost on a PDP-11, and since back then,
all the world was PDP-11, and the only character set which
counted was ASCII, which only uses the lower 7 bits...)
Quote:
It makes an interesting case for dropping that support in the
standard, and go for requirement of two's complement for all
signed integral types.
|
Perhaps a better choice would be to require that plain char be
unsigned, so that you could safely use it with the results of
e.g. istream::get() or fgetc(). (Or both, but I don't think
you'll find much support for either in the committee.)
Quote:
Quote:
Quote:
> Why not implement a buffer using uint8_t ?
|
|
|
Quote:
Quote:
Quote:
That's not presently a standard C++ type.
|
|
|
Quote:
Quote:
It's still a viable alternative.
|
|
Quote:
Yes, and the main reason for "why not" is that it's not a
standard C++ type.
|
Quote:
Quote:
It's possible to write code for binary network protocols in a
perfectly portable manner. It's rarely worth it, since it
entails some very complex work arounds for what are, in the end,
very rare and exotic machines that most of us don't have to deal
with. Thus, I know that much of the networking software I write
professionally will fail on a machine with an unusual convertion
of unsigned to signed (i.e. which isn't 2's complement, and
doesn't just use the underlying bit pattern).
|
|
Quote:
Tune up the warning level, perhaps? <g>
|
What I'm waiting for is a machine which will core dump if the
conversion fails (i.e. doesn't result in the same value). I
don't really expect to see it, however, given that one standard
idiom in C is things like:
int ch = fgetc( input ) ;
while ( ch != EOF && someOtherConditions( ch ) ) {
*p ++ = ch ; // Where p is a char*...
}
It's a bit surprising that something this widespread is
implementation defined, and may result in an implementation
defined signal (according to the C standard---the C++ standard
still has the imprecisions of C90). Because it is so
widespread, however, I don't expect to see a compiler which
doesn't support it anytime soon. (As I said, all of the
"exotic" architectures that I know make plain char unsigned,
which effectively removes the "implementation defined" here.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
