Unsigned char vs. char
Keith Robertson
Is there any reason why you might want to choose an unsigned char
over a plain old char in C++? Note: I have seen this done in code that
will be a part of an embedded system.
Thanks,
Keith
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
William H. Bloodworth
wrote:
That's a good question. There might be several reasons why one might want to
use an
unsigned char instead of a signed char. One possibility could be that a class
created to
represent a person has a data member that represents the age. Since age can't
be negative
(as far as I know) an unsigned char would do the trick nicely. While a signed
char has an
upper limit of 128, an unsigned char has an upper limit of 256...hoping that
will suffice
for an age limit. Hope that is at least close to the sort of answer you're
looking for.
William Bloodworth
Salters
> Hello,
> Is there any reason why you might want to choose an unsigned char
> over a plain old char in C++? Note: I have seen this done in code that
> will be a part of an embedded system.
> Thanks,
> Keith
You need a counter that runs to 256, and also need to use as little memory
as possible? Quite likely for an embedded systeam, I'd say.
Regards,
Michiel Salters
Jack Klein
> Hello,
> Is there any reason why you might want to choose an unsigned char
> over a plain old char in C++? Note: I have seen this done in code that
> will be a part of an embedded system.
> Thanks,
> Keith
Yes, many. For small numbers unsigned chars might have faster
arithmetic on some small processor architectures. Also you might
really, really need unsigned chars and the standard leaves it up to
the implementation to decide whether plain char is signed or not.
And some usages require unsigned char. The character classification
and conversion functions from <cctype> are defined for values in the
range of unsigned char plus EOF. An arbitrary value in a signed char
might turn out to be a negative value in an integer, producing
undefined behavior is used as an argument to these functions.
Jack Klein
--
Home: http://home.att.net/~jackklein
Anthony DeRobertis
<kei...@nortelnetworks.com> wrote:
>Hello,
> Is there any reason why you might want to choose an unsigned char
>over a plain old char in C++? Note: I have seen this done in code that
>will be a part of an embedded system.
Chars may be signed. You might use an unsigned char for the same reason
you'd use any other unsigned type -- to allow you an extra bit worth of
positive numbers.
--
Windows 95 (win-DOH-z), n. A thirty-two bit extension and graphical
shell to a sixteen bit patch to an eight bit operating system
originally coded for a four bit microprocessor which was used in a PC
built by a formerly two bit company that couldn't stand one bit of competition.
Ken Hagan
>Hello,
> Is there any reason why you might want to choose an unsigned char
>over a plain old char in C++? Note: I have seen this done in code that
>will be a part of an embedded system.
Only a broken compiler.
The signed and unsigned chars are simply the smallest integer types
available on your system, a kind of "short short" to parallel the new
"long long" in C9X.
Plain char is for text. Its closest relative is wchar_t ("long char"
anyone?)
and not the other two char types. String literals are const-ish plain chars,
and assigning them to either signed or unsigned char pointers should give
a compiler warning. This makes them ill-suited to text processing, but not
unusable.
Arithmetically, the plain char will behave like one of the other two types.
Sometimes this bites, as when you use a character code greater than
128 as an array index and the program treats it as a negative number.
A half decent compiler will make the plain char "unsigned" if the normal
character set for the target platform is 8-bit. A good compiler will let you
control the signed-ness of plain chars with a switch.
Parag M. Panse
> Hello,
> Is there any reason why you might want to choose an unsigned char
> over a plain old char in C++? Note: I have seen this done in code that
> will be a part of an embedded system.
It is useful when you would like to treat the bytes as numbers.
To site an embedded system example, say you want to use values read from a
status register to index into array. The value read from the status
regsiter is a byte and if it stored in a char it is treated as signed
quantity while index computation, which could potentially result in the
computation of a negative array index. To avoid this unsigned char is
used.
-Parag
Shiva
> That's a good question. There might be several reasons why one might want to
> use an
> unsigned char instead of a signed char. One possibility could be that a class
> created to
> represent a person has a data member that represents the age. Since age can't
> be negative
> (as far as I know) an unsigned char would do the trick nicely. While a signed
> char has an
> upper limit of 128, an unsigned char has an upper limit of 256...hoping that
> will suffice
> for an age limit. Hope that is at least close to the sort of answer you're
> looking for.
It's incorrect to say a signed char has an upper limit of 128 & unsigned
one 256
This depends on the implementation & it's basic character set.
The max & min values are defined in <limits>
--
cheers,
Shiva
http://members.xoom.com/jshiva
clc++ FAQ : http://www.cerfnet.com/~mpcline/c++-faq-lite/
Steve Clamage
> Is there any reason why you might want to choose an unsigned char
>over a plain old char in C++? Note: I have seen this done in code that
>will be a part of an embedded system.
The types char, signed char, and unsigned char are always
distinct, even though they have the same number of bits,
and type char has the same representation and behavior
as either signed char or unsigned char. By analogy, it
is common for types int and long to have the same
representation, although they are always distinct types.
If you want a small unsigned integer object capable of
representing unsigned values in the range 0-255, use unsigned
char. Type "plain" char need not behave as an unsigned type.
If you use the value of these integers in expressions, you
must understand the rules for mixed-mode arithmetic. When
some of the operands in an expression are signed and some
are unsigned, you have to pay close attention to the rules
to get the results you want. Such code tends to be fragile.
Consider whether a signed short or int would be better
overall than an unsigned char. (A signed short must also
be capable of representing values in the range 0-255).
OTOH, if you are using bitwise operations on the values, e.g.
shifting and masking, you probably do want an unsigned
type. The rules of arithmetic and bit operations on unsigned
types are completely defined. Some aspects of arithmetic and
bit operations on signed types depend on the implementation.
If you want to store characters (as opposed to small positive
integers), use "plain" char. That type will have the correct
behavior for all character-oriented classes and functions,
whereas type unsigned char (or signed char) will not always work.
If you want to do arithmetic on characters, you don't have
many really good choices. You should ordinarily use type
"plain" char, but since it can behave as either a signed
or unsigned value, some operations might not behave as you
want unless you use casts or assigment to "larger" integer
types to force specific behavior.
But some arithmetic operations are completely defined for
type char. For example, all the 96 characters in the basic
character set must have a non-negative representation, even
if type char is signed. The values of the integer characters
'0' through '9' must be contiguous in ascending order,
meaning '1'+2 always has the same value as '3'.
--
Steve Clamage, stephen...@sun.com
Modysk
>Hello,
>Is there any reason why you might want to choose
>an unsigned char over a plain old char in C++?
>Note: I have seen this done in code that
>will be a part of an embedded system.
Besides the preceding reason, there is also
the fact that the result of applying a bitwise right shift
to a signed quantity is left to the implementation.
Most implementations, I believe, propagate the most
significant bit, but even so the result is still dependent
on the most significant bit. In the unsigned case only
0's are used to fill the space created on the left, which
might make it more convenient in some cases.
Regards
S. K. Mody
Michael Tiomkin
Keith Robertson wrote in message <37AF0749...@americasm01.nt.com>...
>Hello,
> Is there any reason why you might want to choose an unsigned char
>over a plain old char in C++? Note: I have seen this done in code that
>will be a part of an embedded system.
>Keith
This the same as in C: when you keep bit values in a variable and use
logical operators, like &, |, and >>, you are not interested in adding 1's
as the most significant bits when the value is expanded or shifted.
For example, on many platforms, for a function with the prototype of "int
foo(int bar);", the following two statements
char a = 1<<7; // only 1 bit in the 7th position
foo(a);
will give the function "foo" 25 bits that are set in case that the "char" is
defined as 8-bit signed, the "int" size is 32 bit, and the target platform
uses the standard representation of negative numbers.
When you use numbers as bit masks, it's always better to have them
unsigned. A person who is too lazy to write this long word, can just use a
typedef, like
typedef unsigned char byte;
Michael
Joe Halpin
> Is there any reason why you might want to choose an unsigned char
>over a plain old char in C++? Note: I have seen this done in code that
>will be a part of an embedded system.
One answer I haven't seen yet is that signed integers might not do
what you want with right shifts (or at least, they might not do the
same thing an unsigned integer would). This applies to ints and longs
as well as chars.
For example, this shows that a right shift of an all-bits-set signed
and unsigned char results in different values (on HP-UX, AIX and Linux
anyway). The unsigned version strikes me as more intuitive.
#include <iostream.h>
#include <iomanip.h>
int main()
{
signed char sc;
unsigned char uc;
sc = 0xff;
uc = 0xff;
cout << hex;
cout << "sc = " << ((int) sc & 0xff) << '\n';
cout << "uc = " << ((int) uc & 0xff) << '\n';
sc >>= 1;
uc >>= 1;
cout << "sc = " << ((int) sc & 0xff) << '\n';
cout << "uc = " << ((int) uc & 0xff) << '\n';
Mungo Henning
"William H. Bloodworth" wrote:
> On 9 Aug 1999 18:24:08 -0400, "Keith Robertson" <kei...@nortelnetworks.com>
> wrote:
>
> upper limit of 128, an unsigned char has an upper limit of 256...hoping that
> will suffice
>
Close, but 127 and 255 are the end-points to be precise.
Mungo
--
Mungo Henning - it's a daft name but it goes with the face...
mungoh@itacs.strath.ac.uk.http://www.itacs.strath.ac.uk/
I speak for me, not my employer.
Modysk
>Hello,
>Is there any reason why you might want to choose
>an unsigned char over a plain old char in C++?
>Note: I have seen this done in code that
>will be a part of an embedded system.
Besides the preceding reason, there is also
the fact that the result of applying a bitwise right shift
to a signed quantity is left to the implementation.
Most implementations, I believe, propagate the most
significant bit, but even so the result is still dependent
on the most significant bit. In the unsigned case only
0's are used to fill the space created on the left, which
might make it more convenient in some cases.
Regards
S. K. Mody
Christopher Eltschka
>
> Hello,
> Is there any reason why you might want to choose an unsigned char
> over a plain old char in C++? Note: I have seen this done in code that
> will be a part of an embedded system.
Whenever you deal with raw data.
If char is signed, and the machine uses sign/magnitude or ones
complement, there are two representations meaning 0. Thus you
cannot rely even on
char* foo = some_address();
*foo = *foo;
not changing your memory. With unsigned char, you _know_
you're not changing anything here. The same is true for
the test for equality: With plain char, the two different
representations of 0 will compare equal, despite having
different bit patterns.
Also, unsigned types have well defined behaviour on
overflow/underflow, while signed types have undefined
behaviour in this case. There might be a need for this.
Modysk
<37AF0749...@americasm01.nt.com>:-
>Hello,
>Is there any reason why you might want to choose
>an unsigned char over a plain old char in C++?
>Note: I have seen this done in code that
>will be a part of an embedded system.
Besides the preceding reason, there is also
the fact that the result of applying a bitwise right shift
to a signed quantity is left to the implementation.
Most implementations, I believe, propagate the most
significant bit, but even so the result is still dependent
on the most significant bit. In the unsigned case only
0's are used to fill the space created on the left, which
might make it more convenient in some cases.
Regards
S. K. Mody
William H. Bloodworth
>
>
>"William H. Bloodworth" wrote:
>
>> On 9 Aug 1999 18:24:08 -0400, "Keith Robertson" <kei...@nortelnetworks.com>
>> wrote:
>>
>> upper limit of 128, an unsigned char has an upper limit of 256...hoping that
>> will suffice
>>
>
>Close, but 127 and 255 are the end-points to be precise.
>
>Mungo
Yes, I was very tired when I made this post; no excuses though!
William
=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net" ICQ: 21901934
=
= Software Engineer && "Acting" Consultant Manager - The Maxim Group
=====================================================================
William H. Bloodworth
>"William H. Bloodworth" wrote:
>> That's a good question. There might be several reasons why one might want to
>> use an
>> unsigned char instead of a signed char. One possibility could be that a class
>> created to
>> represent a person has a data member that represents the age. Since age can't
>> be negative
>> (as far as I know) an unsigned char would do the trick nicely. While a signed
>> char has an
>> upper limit of 128, an unsigned char has an upper limit of 256...hoping that
>> will suffice
>> for an age limit. Hope that is at least close to the sort of answer you're
>> looking for.
>
>It's incorrect to say a signed char has an upper limit of 128 & unsigned
>one 256
>This depends on the implementation & it's basic character set.
>The max & min values are defined in <limits>
You're absoulutely correct. Touche'!
Anthony DeRobertis
mun...@itacs.strath.ac.uk wrote:
>"William H. Bloodworth" wrote:
>
>> On 9 Aug 1999 18:24:08 -0400, "Keith Robertson" <kei...@nortelnetworks.com>
>> wrote:
>>
>> upper limit of 128, an unsigned char has an upper limit of 256...hoping that
>> will suffice
>>
>
>Close, but 127 and 255 are the end-points to be precise.
But does the Standard actually require 8-bit two's-complement chars? Not sure :)
--
Windows 95 (win-DOH-z), n. A thirty-two bit extension and graphical
shell to a sixteen bit patch to an eight bit operating system
originally coded for a four bit microprocessor which was used in a PC
built by a formerly two bit company that couldn't stand one bit of competition.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
ialup.rcn.com>, Anthony DeRobertis <dero...@erols.com> writes
>But does the Standard actually require 8-bit two's-complement chars? Not sure :)
It certainly does not require exactly 8-bits, only at least 8. I'd have
to check to see if it further constrained the representation. C only
required a binary representation (2's complement, 1's complement or sign
and value are all that I think fit that requirement)
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Carl Barron
ISO stsndard 3.9.1.7
= almost quoted [I hate not being able to extract text from this pdf:)]
Types bool,char.wchar_t and their signed and unsigned versions are
collectively called integral typess... The representattion of integral
types shall define values by use of a pure binsry numeration system.
[Example this International Standard permits 2's compliment,1's
compliment, and signed magnitude representation for integral types.]
= end almost quoted.
Francis Glassborow
Barron <cbar...@ix.netcom.com> writes
> ISO stsndard 3.9.1.7
> = almost quoted [I hate not being able to extract text from this pdf:)]
>
> Types bool,char.wchar_t and their signed and unsigned versions are
>collectively called integral typess... The representattion of integral
>types shall define values by use of a pure binsry numeration system.
>[Example this International Standard permits 2's compliment,1's
>compliment, and signed magnitude representation for integral types.]
>
>= end almost quoted.
Thanks for looking it up.
Mungo Henning
Carl Barron wrote:
> Types bool,char.wchar_t and their signed and unsigned versions are
> collectively called integral typess... The representattion of integral
> types shall define values by use of a pure binsry numeration system.
> [Example this International Standard permits 2's compliment,1's
> compliment, and signed magnitude representation for integral types.]
Having been duly corrected, anyone want to spell out the difference between
these three nomenclatures for integers please? With (say) a six bit number,
how would the values -24, 0 and 42 be represented?
I'm loathe to agree with "All the world's a VAX" sentiment outlined in Henry
Spencer's "Ten Commandments for C Programmers", but anyone have a
feel for what percentage of the world's processors use two's complement
notation?
TIA,
Mungo
Incidentally, is there a similar "Ten Commandments" for C++ anywhere on
the internet, and if so is it more than ten long?
--
Mungo Henning - it's a daft name but it goes with the face...
mungoh@itacs.strath.ac.uk.http://www.itacs.strath.ac.uk/
I speak for me, not my employer.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<mun...@itacs.strath.ac.uk> writes
>Having been duly corrected, anyone want to spell out the difference between
>these three nomenclatures for integers please? With (say) a six bit number,
>how would the values -24, 0 and 42 be represented?
>I'm loathe to agree with "All the world's a VAX" sentiment outlined in Henry
>Spencer's "Ten Commandments for C Programmers", but anyone have a
>feel for what percentage of the world's processors use two's complement
>notation?
There is no difference between the three binary representations for
positive values. For negative values start with the bit representation
for the absolute value. for -24, we start with the representation of 24
which is 0011000.
Now, for sign and value simply set the high bit to give 1011000
for 1's complement flip all the bits to give 1100111
and for twos complement add 1 to the 1's complement to give 1101000
Each mechanism has some advantages, though 2's complement largely wins
the day. Note that each of the representations shares the property that
negating a negative value returns you to the equivalent positive value.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Darin Adler
> Having been duly corrected, anyone want to spell out the difference between
> these three nomenclatures for integers please? With (say) a six bit number,
> how would the values -24, 0 and 42 be represented?
-24 (decimal):
two's complement: 101000
one's complement: 100111
signed magnitude: 111000
0:
two's complement: 000000
one's complement: 000000
signed magnitude: 000000
With 6 bits and two's complement, you get a range of -32 to 31.
With 6 bits and one's complement, you get a range of -31 to 31.
With 6 bits and signed magnitude, you get a range of -31 to 31.
The value 42 (decimal) can not be represented in six bits in any of these
schemes.
-- Darin
Thant Tessman
Darin Adler wrote:
>
> 0:
>
> two's complement: 000000
> one's complement: 000000
or 111111 (negative zero)
>
> signed magnitude: 000000
or 100000 (negative zero)
-thant
Anthony DeRobertis
<fran...@robinton.demon.co.uk> wrote:
>Each mechanism has some advantages, though 2's complement largely wins
>the day. Note that each of the representations shares the property that
>negating a negative value returns you to the equivalent positive value.
Not two's complement -- if you negate the lowest negative value, you don't
get the same absolute value.
--
Windows 95 (win-DOH-z), n. A thirty-two bit extension and graphical
shell to a sixteen bit patch to an eight bit operating system
originally coded for a four bit microprocessor which was used in a PC
built by a formerly two bit company that couldn't stand one bit of competition.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James...@dresdner-bank.com
mun...@itacs.strath.ac.uk wrote:
> I'm loathe to agree with "All the world's a VAX" sentiment outlined in
> Henry Spencer's "Ten Commandments for C Programmers", but anyone have
> a feel for what percentage of the world's processors use two's
> complement notation?
It doubtlessly depends on whether you are concerned with number of
different architectures, or number of actual machines in use. It also
probably depends on whether you exclude machines on which you couldn't
implement C anyway -- I've worked on small embedded processors that had
*no* signed arithmetic. Globally, however, excluding processors without
signed arithmetic, and only counting processors currently being
marketed. I'm sure the percentage is over 99%, regardless of how you
measure it. (I'm only aware of one "modern" processor that doesn't use
two's complement. And it isn't a particularly big seller.)
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
James...@dresdner-bank.com
om>
<auOznQAC...@robinton.demon.co.uk>
<1dwy0hm.in5...@buf-ny1-02.ix.netcom.com>
<37C299F5...@itacs.strath.ac.uk>
<6RBLYnAB...@robinton.demon.co.uk>
<derobert-270...@209-122-239-11.s265.tnt2.lnh.md.dialup.rcn.co
m>
X-Clcppm-Sequence: 3935
X-Original-Date: Tue, 31 Aug 1999 12:25:15 GMT
X-Submission-Address: c++-s...@netlab.cs.rpi.edu
In article
<derobert-270...@209-122-239-11.s265.tnt2.lnh.md.dialup.rcn.co
m>,
dero...@erols.com (Anthony DeRobertis) wrote:
> In article <6RBLYnAB...@robinton.demon.co.uk>, Francis Glassborow
> <fran...@robinton.demon.co.uk> wrote:
> >Each mechanism has some advantages, though 2's complement largely
> >wins the day. Note that each of the representations shares the
> >property that negating a negative value returns you to the equivalent
> >positive value.
> Not two's complement -- if you negate the lowest negative value, you
> don't get the same absolute value.
Strictly speaking, you get undefined behavior, but on all of the
implementations I've seen, you get the same absolute value. It's the
sign, not the absolute value, which is wrong.
Dennistjoh
>two's complement. And it isn't a particularly big seller.)
OK I will bite, what is this computer called and what is the manufacture?
Thanks Dennis :-)) remove nospam for e-mail
James...@dresdner-bank.com
denni...@aol.comnospam (Dennistjoh) wrote:
> > (I'm only aware of one "modern" processor that doesn't use
> >two's complement. And it isn't a particularly big seller.)
> OK I will bite, what is this computer called and what is the
> manufacture?
Unisys Series A, or something similar. (The original architecture comes
from Burroughs.) It uses 48 bit signed magnitude ints, with 8 bits
which are unused, and must be 0.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]