Why is "Hello World" const char* ?

[Hans]

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 [])

??

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'.

Thanks!

Hans

[Emmanuel Delahaye]

Hans wrote on 05/02/05 :

Why all C/C++ guys write:
There is no such thing like 'C/C++'. There is C and there is C++. They
are different languages (e.g. in C, 'A' is an int and in C++, 'A' is a
char)
const char* str = "Hello";

or

const char[] str = "Hello";
Both are correct, but have different semantic (pointer vs array).
Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

??
Would be a type error sometimes.
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'.

A 'char', an 'unsigned' char and a 'signed char' are three different
types. The type for a string (an array of 'char' terminated by a 0) is
.... 'char'. Period.

Note that depending on the implementation, a 'char' car be signed or
unsigned. Use constants defined in <limits.h> to get the current range
values.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Sam]

> Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

??

It is not important whether char is signed or unsigned here. If you do some
maths things with char like
char a;
a = 127;
a++;
if(a > 0)....
whether it is signed or not may be a problem. But when you just wanna handle
text, it makes no difference.

[Ioannis Vranos]

Hans wrote:

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

int main()
{
const unsigned char* str = "Hello";
}
The error messages say it all:
C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:3: error: invalid conversion from `const char*' to `const unsigned
char*'
temp.cpp:4:2: warning: no newline at end of file

C:\c>cl temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
temp.cpp(3) : error C2440: 'initializing' : cannot convert from 'const
char [6]'
to 'const unsigned char *'
Types pointed to are unrelated; conversion requires
reinterpret_cast, C-
style cast or function-style cast

C:\c>


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Mike Wahler]

"Hans" <Ha**@replyingrouptoavoidspam.com> wrote in message
news:cu**********@news4.zwoll1.ov.home.nl...

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 [])

??

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'.

C does not require the ASCII character set.

-Mike

[Luke Wu]

Hans wrote:

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).

Thanks!

Hans

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.

[Luke Wu]

Luke Wu wrote:

Hans wrote:

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

by -73 I meant -56 :-)


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).

[James McIninch]

A string literal is of type 'const char *' in C. Best to declare the
variable as being the same type as the data it is storing.
Hans wrote:

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 [])

??

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'.

Thanks!

Hans

--
Remove '.nospam' from e-mail address to reply by e-mail

[john_bode]

Hans wrote:

Hello,

Why all C/C++ guys write:

const char* str = "Hello";

C++ guys don't use char arrays or pointers to char for text data if
they can help it; that's what the std::string datatype is for.
or

const char[] str = "Hello";

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

Because the type of a string literal is "const char *", not "const
unsigned char*".

Secondly, the plain, unqualified char type may be signed or unsigned,
or a mixture of both, depending on the implementation. The char type
is not treated exactly the same as other signed and unsigned integral
types.
??

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'.

Thanks!

Hans

[infobahn]

James McIninch wrote:

A string literal is of type 'const char *' in C.
No, it isn't. It has an array of char, with static storage duration.
It's "const" only in the sense that modifying it invokes undefined
behaviour; "constant" or even "read-only" would be a better
description.
Best to declare the
variable as being the same type as the data it is storing.

Then do this:

static char foo[] = "string literal";

but not everybody here will agree that this is always best!

[Luke Wu]

jo*******@my-deja.com wrote:

Hans wrote:

Hello,

Why all C/C++ guys write:

const char* str = "Hello";

C++ guys don't use char arrays or pointers to char for text data if
they can help it; that's what the std::string datatype is for.

or

const char[] str = "Hello";

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

Because the type of a string literal is "const char *", not "const
unsigned char*".

Your statement is incorrect. Neve A string literal is an array of
(const char) representing each of the characters within quotation " "
and an extra element thereafter to terminate it: NUL. rtheless, when
using a string literal in quotations " " in value contexts, like
assignments, C automatically replaces the string literal (which at this
point in runtime or compile time is guaranteed to be allocated already)
with a pointer value pointing to its first character (to take part in
the expression). Since the first character is of type (const char) as
we mentioned earlier, the type of the pointer value is (const char *)-
pointer to const char.

Try not to say "a string literal is a pointer to (const) char," because
it is an incorrect statement (even though people will understand it,
they might think less of you).

Secondly, the plain, unqualified char type may be signed or unsigned,
or a mixture of both, depending on the implementation. The char type
is not treated exactly the same as other signed and unsigned integral
types.

??

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'.

Thanks!

Hans

[Keith Thompson]

James McIninch <ja*******************@comcast.net> writes:

A string literal is of type 'const char *' in C.

No, it isn't, it's of type 'char *' (but attempting to modify the
content invokes undefined behavior). This may be different in C++ --
which is one of the reasons cross-posting to comp.lang.c and
comp.lang.c++ is rarely a good idea.

I haven't set followups on this reply, but think carefully when you
post.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Sam wrote:

.... snip ...
It is not important whether char is signed or unsigned here. If
you do some maths things with char like
char a;
a = 127;
a++;
if(a > 0)....
whether it is signed or not may be a problem. But when you just
wanna handle text, it makes no difference.

For just one example, it matters when classifying chars with the
routines in ctype.h. Use of signed chars can cause UB.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Barry Schwarz]

On 5 Feb 2005 09:49:26 -0800, "Luke Wu" <Lo***********@gmail.com>
wrote:

Hans wrote:

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.

Even though the string literal is not modifiable, the pointer is of
type char*, without the const.

snip
<<Remove the del for email>>

[Barry Schwarz]

On Sat, 05 Feb 2005 14:45:11 -0500, James McIninch
<ja*******************@comcast.net> wrote:

A string literal is of type 'const char *' in C. Best to declare the
variable as being the same type as the data it is storing.

A string literal is of type array of char. You can verify this by
applying the sizeof operator to it. In most expressions, a string
literal evaluates to the address of the first char with type char*,
but still no const.
snip
<<Remove the del for email>>

[Jack Klein]

On 5 Feb 2005 09:49:26 -0800, "Luke Wu" <Lo***********@gmail.com>
wrote in comp.lang.c:

Hans wrote:

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.

No, in C a string literal in ANY context is an array of char, not
const char, and the address of a string literal has the type "pointer
to char" and NOT "pointer to const char".

In C attempting to modify a string literal produces undefined behavior
because the C standard specifically says so, not because the literal
has the type "array of const char".
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*).

A pointer to a non-const object of any type 'T', or the address of a
non-const object of any type 'T', can always be assigned directly to a
pointer to const 'T', in both C and C++. So the issue is not the
const, it is the fact that a pointer to plain char is incompatible
with a pointer to unsigned char, regardless of whether plain char is
signed or not. That is what requires a cast.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 5 Feb 2005 12:55:31 -0800, "Luke Wu" <Lo***********@gmail.com>
wrote in comp.lang.c:

jo*******@my-deja.com wrote:

Hans wrote:

Hello,

Why all C/C++ guys write:

const char* str = "Hello";

C++ guys don't use char arrays or pointers to char for text data if
they can help it; that's what the std::string datatype is for.

or

const char[] str = "Hello";

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

Because the type of a string literal is "const char *", not "const
unsigned char*".

Your statement is incorrect. Neve A string literal is an array of
(const char) representing each of the characters within quotation " "
and an extra element thereafter to terminate it: NUL. rtheless, when
using a string literal in quotations " " in value contexts, like
assignments, C automatically replaces the string literal (which at this
point in runtime or compile time is guaranteed to be allocated already)
with a pointer value pointing to its first character (to take part in
the expression). Since the first character is of type (const char) as
we mentioned earlier, the type of the pointer value is (const char *)-
pointer to const char.

Since you are talking about C specifically here, you are just plain
wrong. The type of a string literal is "array of char", NOT "array of
const char". The address of a string literal has the type "pointer to
char", NOT "pointer to const char".

Either you think the rules of some other language apply to C, or you
just don't know C as well as you think you do.
Try not to say "a string literal is a pointer to (const) char," because
it is an incorrect statement (even though people will understand it,
they might think less of you).

Right, both because a string literal is not a pointer, and because its
address is a pointer to char, not a pointer to const char.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Joe Wright]

Sam wrote:

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

??

It is not important whether char is signed or unsigned here. If you do some
maths things with char like
char a;
a = 127;
a++;
if(a > 0)....
whether it is signed or not may be a problem. But when you just wanna handle
text, it makes no difference.

Really? Is the character é (130) within your definition of text?
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Emmanuel Delahaye]

Ioannis Vranos wrote on 05/02/05 :

Hans wrote:

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

int main()
{
const unsigned char* str = "Hello";
}

The error messages say it all:

C:\c>g++ temp.cpp -o temp.exe

Wait a minute... We are talking C here. C++ is next door...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

[Ron Natalie]

Luke Wu wrote:

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.

Nope, it evaluates to an array of char, which converts to pointer to
char. The characters are effectively const (it is undefined behvaior
to attempt to change them), but the type of the expression is not
const char*. (except when sizeof or & is applied to the array value).

It's effectively the same in C++, except C++ defines a formal array-to-pointer
conversion.

[CBFalconer]

Ron Natalie wrote:

Luke Wu wrote:

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.

Nope, it evaluates to an array of char, which converts to pointer
to char. The characters are effectively const (it is undefined
behvaior to attempt to change them), but the type of the
expression is not const char*. (except when sizeof or & is
applied to the array value).

It's effectively the same in C++, except C++ defines a formal
array-to-pointer conversion.

However it is advisable to declare such strings as:

const char *foo = "foobar";

so that the C compiler can emit suitable warnings on misuse, such
as trying to alter it with such things as *foo = 'F'; Note that
foo = "barfoo"; is perfectly legal, except you may never find the
"foobar" string again.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[msalters]

Ron Natalie wrote:

Luke Wu wrote:

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.
Nope, it evaluates to an array of char, which converts to pointer to
char. The characters are effectively const (it is undefined

behvaior to attempt to change them), but the type of the expression is not
const char*. (except when sizeof or & is applied to the array value).
It's effectively the same in C++, except C++ defines a formal
array-to-pointer conversion.

No, it isn't. In C++ it is definitely an array of N const char, see
2.13.4
and overloading will show that. There is a deprecated limited
conversion
to non-const char*.
Furthermore, even in sizeof( "literal") the type is not const char*,
this will be the true size of the literal object.

( restricted to clc++)

HTH,
Michiel Salters

[Lawrence Kirby]

On Sat, 05 Feb 2005 12:18:22 -0800, john_bode wrote:

Hans wrote:

Hello,

Why all C/C++ guys write:

const char* str = "Hello";

C++ guys don't use char arrays or pointers to char for text data if
they can help it; that's what the std::string datatype is for.

or

const char[] str = "Hello";

Why is this not a more elegant way:

const unsigned char* str = "Hello"; (or [])

Because the type of a string literal is "const char *", not "const
unsigned char*".

As others have said its type is array of char. But the fact that it is
char and not unsigned char is significant.

Another thing that is just as significant is the fact that standard
library functions that take or generate strings have arguments/return
values derived from type char, not unsigned char.
Secondly, the plain, unqualified char type may be signed or unsigned, or
a mixture of both, depending on the implementation. The char type is
not treated exactly the same as other signed and unsigned integral
types.

I'm not sure what you mean by a "mixture of both". For any particular
implementation plain char must behave exclusively like either signed char
or unsigned char, except that it is a different type. Think of it like int
and long. On some implementations they have the same representation but
even when that is true they are different types.

Lawrence

[Ron Natalie]

msalters wrote:

Ron Natalie wrote:

Luke Wu wrote:

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.

Nope, it evaluates to an array of char, which converts to pointer to
char. The characters are effectively const (it is undefined

behvaior

to attempt to change them), but the type of the expression is not
const char*. (except when sizeof or & is applied to the array

value).

It's effectively the same in C++, except C++ defines a formal
array-to-pointer conversion.

No, it isn't. In C++ it is definitely an array of N const char, see
2.13.4

You're right of course. When I wrote the "same in C++" I was refering
to the type being an ARRAY, not a pointer as the previous poster referred to.