Hans said:
Hello,
Why all C/C++ guys write:
const char* str = "Hello";
or
const char[] str = "Hello";
Why is this not a more elegant way:
const unsigned char* str = "Hello"; (or [])
In C, a string literal (like "Hello") in value context (like the right
side of an assignment= operator) evaluates to a pointer value of type
(const char*) that points to the first character.
So you are mixing types here. You are trying to assign a VALUE of type
(const char*) to an LVALUE/OBJECT of type (const unsigned char*).
??
My Reasson: have you ever seen ASCII-Code: -50? The extended ASCII Set
(>127) would be represented by a negative number if you use 'char'
instead of 'unsigned char'.
You are right, but C (and associated function) still know that if you
every use that character for the purposes of dealing with a text
character, to treat the value as a positive value before comparing it
against the local character set. The very fact that your first sentence
claims it to be an ASCII character, means you will not likely use that
character value as simply an integer in computations that will be
malicious to your intents. If you want to use char storage simply to
hold integer values for computations, then specify signed/unsigned.
Of course, there are times when you want to do computations with chars
that hold text characters, and in those instances it usually never
matters whether char is equivalent to singed or unsigned. For example,
if you want to convert the text representation of a numeric character
to it's integer equivalent, you can do something like this:
char c = '7'; /* c holds value corresponding to '7' in character set */
char d = '4'; /* d holds character '4' */
int num;
num = c - d - '0'; /* num now holds integer value 3 */
In the above example, it didn't matter whether char was equivalent to
signed or unsigned, because we are using char to hold text characters
(and later use it in computations with other text characters in
computations).
It's true that some character sets can take up values from between 128
to 255, but that doesn't prevent an implementation from making 'char'
equivalent to 'signed char' (intead of 'unsigned char').
When dealing with text/strings, the signess of the char type has no
effect on normal use.
Say you have set up an array of ASCII characters corresponding to
decimal= 200. Will you ever use array for the sake of it's value 200,
or only as an array to represent the ASCII text characters (the latter
of course- read the first sentence of the paragraph)? Sure, the chars
have integer values of -73, but when you want deal with strings/text
their context automatically tells associated functions to treat
whatever is held in the character variables as a positive quantity.
For example, putchar(-73) <=== try that
It doesn't matter that we're sending an integer value of -73, putchar
knows that it must be treated as an unsigned positive value (puthcar
accepts integers, even when we hand it a char variable, it's promoted
an integer).
So when using a char type to represent a character, it doesn't matter
whether it is equivalent to signed or unsigned char. On the other
hand, if you want to use a char type to simple act as a small integer,
then you should specify a qualifier (signed or unsigned), because the
contexts you will use these objects in will probably rely on their
signess.
