difference between [] and *

Unless there's something in the brackets that you aren't mentioning, then I think they're slightly different. The first is a pointer to nothing in particular (at least until you point it to something). The second is a pointer to an array of unspecified length. It should have some acutal memory allocated for it somewhere else...

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor

Yanroy@usa.com

[edited by - Yanroy on August 7, 2003 1:35:52 PM]

not satisfied... anyone else wanna say something ? Any C/C++ guru around ?

array name = pointer to first element

If you have...
char hithere[5];

Then...
hithere[2] == *(hithere + 2)

EDIT: The above AP is me.

[edited by - Way Walker on August 7, 2003 4:20:36 PM]

extern char strVersion[]: Implies that somewhere, in another compilation unit, there is some memory that is an array of chars named strVersion.

extern char* strVersion: Implies that somewhere, in another compilation unit, there is some memory that is a pointer to a location in memory that stores char(s).

Obviously, you've never actually allocated memory for a pointer anywhere, only the chars it would point to. So your C side is seeing strVersion, taking the first four characters of it, and assuming that that's a pointer to somewhere in memory with chars. Mayhem, predictably, ensues.

---

How appropriate. You fight like a cow.

[edited by - sneftel on August 7, 2003 4:26:20 PM]

they are the same if you do not specify a number in the brackets. the [] operator is shorthand for pointer arithmatic. for example :

f[10] == *(f + sizeof(char) * 10); // if f is a char array

if the size of the array is specified then the array is allocated on the stack. using the new operator puts it on the heap (i think).

Sneftel is, of course , right.

char x[] = "string"; puts "string" into the .data segment and operations on this will directly reference that data.

char *x = "string"; also puts "string" into the .data segment, but is, itself, merely a pointer to that data, rather than the data itself. (someone with a little more expertise can tell us if the pointer value would be .bss or .data, assuming a global variable, of course. my guess is .bss)

I must agree to what Sneftel says. It may be confusing, that pointers and arrays behave similar in many cases, but an array variable is not the same as a pointer. If I am right, this has been discussed in that forum some time ago.

f[10] == *(f + sizeof(char) * 10); // if f is a char array

Watch out, if sizeof(char) is not 1 then you are in serious trouble. Doing + with a pointer increases it in increments of the size of the pointer, you don''t have to do it yourself.

Also, be very careful modifying those variables.

The first one could be a pointer to constant memory, whereas the second one could not.

char *temp = "Hello World.";
char blah[] = "Hello World.";

strtok(temp, " ,\t\n"); // Will probably crash.
strtok(blah, " ,\t\n"); // Won''t crash.

quote:

---

Original post by Raloth
Watch out, if sizeof(char) is not 1

---

It IS always 1. period.

char is 1 byte. If you want a wide character, use wchar_t.

quote:

---

Original post by C-Junkie

quote:

---

Original post by Raloth
Watch out, if sizeof(char) is not 1

---

It IS always 1. period.

---

... unless, say, you redefined char to be wchat_t, for say, internationalization ...

... or maybe some compilers that actually have internationalization support built in ...

he is trying to point out a bug in the code anyways. There shouldn''t be the sizeof statement in there at all.

aka: f[10] == *(f + 10) for any type.
but: f[10] == *(f + sizeof( type ) * 10) is incorrect.

... so no more random attacks for the hell of it ...

quote:

---

Original post by MaulingMonkey
... unless, say, you redefined char to be wchat_t, for say, internationalization ...

---

Which, of course, you would NEVER do, because redefining keywords is disallowed by the standard...

quote:

---

... or maybe some compilers that actually have internationalization support built in ...

---

Not that would change the size of char; this would break so much code, it''s not even funny.

quote:

---

he is trying to point out a bug in the code anyways. There shouldn''t be the sizeof statement in there at all.

aka: f[10] == *(f + 10) for any type.
but: f[10] == *(f + sizeof( type ) * 10) is incorrect.

---

I''m pretty sure that SR was pointing exactly this out, implying that the compiler would automultiply by the type size. It would''ve been more clear with casts, tho:

f[10] == *(char*)((int)f + sizeof(char) * 10); // if f is a char array

quote:

---

... so no more random attacks for the hell of it ...

---

But it''s sooo much fun!

---

How appropriate. You fight like a cow.

quote:

---

Original post by Sneftel

quote:

---

Original post by MaulingMonkey
... unless, say, you redefined char to be wchat_t, for say, internationalization ...

---

Which, of course, you would NEVER do, because redefining keywords is disallowed by the standard...

quote:

---

... or maybe some compilers that actually have internationalization support built in ...

---

Not that would change the size of char; this would break so much code, it''s not even funny.

---

Valid points, but my original point is it''s bad to assume .

quote:

---

quote:

---

he is trying to point out a bug in the code anyways. There shouldn''t be the sizeof statement in there at all.

aka: f[10] == *(f + 10) for any type.
but: f[10] == *(f + sizeof( type ) * 10) is incorrect.

---

I''m pretty sure that SR was pointing exactly this out, implying that the compiler would automultiply by the type size. It would''ve been more clear with casts, tho:

f[10] == *(char*)((int)f + sizeof(char) * 10); // if f is a char array

---

Not only more clear, but not in error for non char types, which would be the only reason for including the sizeof(char) item in the first place.

quote:

---

quote:

---

... so no more random attacks for the hell of it ...

---

But it''s sooo much fun!

---

How appropriate. You fight like a cow.

---

---

* goes into a fury *

actually...yeah it IS fun .

There was a post somewhere explaining that char doesn''t have to be 1 byte by the standards. It just happens that the major compilers make it 1, and all the characters you could want fit into 1 byte. But technically it can be greater than 1...