array -- foo, &foo and &foo[0]
-
Hello everyone, I think if we define foo as char array, for example, char foo [32]; then foo, &foo and &foo[0] should be the same, right? For example, the following 3 statements are the same, strcpy (foo, goo); strcpy (&foo, goo); strcpy (&foo[0], goo); Any comments? I am very interested in how C treats foo and &foo and make them the same? thanks in advance, George
-
Hello everyone, I think if we define foo as char array, for example, char foo [32]; then foo, &foo and &foo[0] should be the same, right? For example, the following 3 statements are the same, strcpy (foo, goo); strcpy (&foo, goo); strcpy (&foo[0], goo); Any comments? I am very interested in how C treats foo and &foo and make them the same? thanks in advance, George
I think that you will find this to be compiler dependent. foo is the array, so C/C++ treats the array name as a pointer to the array and thus it is a pointer of the same value as &foo[0]. With some compilers however, I have seen where the compiler stores a pointer to the array (like &foo[0] and then &foo is a pointer to that pointer... so I would stay away from this syntax. Jim
-
I think that you will find this to be compiler dependent. foo is the array, so C/C++ treats the array name as a pointer to the array and thus it is a pointer of the same value as &foo[0]. With some compilers however, I have seen where the compiler stores a pointer to the array (like &foo[0] and then &foo is a pointer to that pointer... so I would stay away from this syntax. Jim
Thanks Jim, I have tested that on Visual Studio, foo and &foo are the same. I think you mean on some other compiler, they may be different. Here is my test program in Visual Studio.
int main (int argc, char** argv) { char foo [1024]; unsigned int p; unsigned int q; p = foo; q = &foo; return 0; }I am interested in the cases when "&foo is a pointer to that pointer". I am wondering what is wrong if I still treat foo and &foo the same in this situation? Could you provide more information and analysis please? regards, George -
Hello everyone, I think if we define foo as char array, for example, char foo [32]; then foo, &foo and &foo[0] should be the same, right? For example, the following 3 statements are the same, strcpy (foo, goo); strcpy (&foo, goo); strcpy (&foo[0], goo); Any comments? I am very interested in how C treats foo and &foo and make them the same? thanks in advance, George
I was a little intrigued by your question, and made up a little test...
UINT p, q; char foo \[100\]; p = (UINT)foo; q = (UINT) (&foo); ASSERT(p == q); char \*bar = foo; p = (UINT) bar; q = (UINT) (&bar); ASSERT(p == q);And you were indeed right. foo and &foo were the same value, but bar and &bar were not. Part of the problem is that we're both cheating and looking at the variables as raw numbers (which I find useful to do conceptually), but the compiler has the advantage of looking at them knowing there type. So foo is a number, but is known to be an array, while &foo happens through an implementation detail you can't rely on to be true on another day of the week to be the same number, but is treated differently as it has a different type (pointer to an array). Hard casting like you did can be useful, but it can also be dangerous. Short answer: compiler dependent. If you rely on it, prepare to be shot in the foot. Iain.
-
I was a little intrigued by your question, and made up a little test...
UINT p, q; char foo \[100\]; p = (UINT)foo; q = (UINT) (&foo); ASSERT(p == q); char \*bar = foo; p = (UINT) bar; q = (UINT) (&bar); ASSERT(p == q);And you were indeed right. foo and &foo were the same value, but bar and &bar were not. Part of the problem is that we're both cheating and looking at the variables as raw numbers (which I find useful to do conceptually), but the compiler has the advantage of looking at them knowing there type. So foo is a number, but is known to be an array, while &foo happens through an implementation detail you can't rely on to be true on another day of the week to be the same number, but is treated differently as it has a different type (pointer to an array). Hard casting like you did can be useful, but it can also be dangerous. Short answer: compiler dependent. If you rely on it, prepare to be shot in the foot. Iain.
Thanks Iain, So, the best practice is not to use &foo? :-) regards, George
-
Thanks Iain, So, the best practice is not to use &foo? :-) regards, George
There's nothing wrong with using &foo - but not as a number. Use it as a "pointer to an array" and let the compiler worry about location details. "Is it wrong to do..." is not something I can possibly answer in the general case. But taking your strcpy example...
char foo [100];
strcpy (foo, "iain"); is fine
strcpy (&(foo[0]), "iain"); is fine, but ugly
strcpy (&foo, "iain"); is syntactically wrong, and I'm surprised you don't get a warning at least. It just happens to work on this compiler.char *bar = new char [100];
strcpy (bar, "iain"); is fine
strcpy (&(bar[0]), "iain"); is fine, but ugly
strcpy (&bar, "iain"); will fail - and mostlikely crash stuff.As you see, the only difference between "getting away with it", and "failing" is what's written a few lines up, relying on &array == array is a really bad idea, even if you will always get away with it. Imagine you come back in 3 years, your boss says "this needs to be longer - make it dynamically sized", and your code will crash with you being puzzled. Iain.
-
There's nothing wrong with using &foo - but not as a number. Use it as a "pointer to an array" and let the compiler worry about location details. "Is it wrong to do..." is not something I can possibly answer in the general case. But taking your strcpy example...
char foo [100];
strcpy (foo, "iain"); is fine
strcpy (&(foo[0]), "iain"); is fine, but ugly
strcpy (&foo, "iain"); is syntactically wrong, and I'm surprised you don't get a warning at least. It just happens to work on this compiler.char *bar = new char [100];
strcpy (bar, "iain"); is fine
strcpy (&(bar[0]), "iain"); is fine, but ugly
strcpy (&bar, "iain"); will fail - and mostlikely crash stuff.As you see, the only difference between "getting away with it", and "failing" is what's written a few lines up, relying on &array == array is a really bad idea, even if you will always get away with it. Imagine you come back in 3 years, your boss says "this needs to be longer - make it dynamically sized", and your code will crash with you being puzzled. Iain.
Great comments, thanks Iain! regards, George
-
Thanks Jim, I have tested that on Visual Studio, foo and &foo are the same. I think you mean on some other compiler, they may be different. Here is my test program in Visual Studio.
int main (int argc, char** argv) { char foo [1024]; unsigned int p; unsigned int q; p = foo; q = &foo; return 0; }I am interested in the cases when "&foo is a pointer to that pointer". I am wondering what is wrong if I still treat foo and &foo the same in this situation? Could you provide more information and analysis please? regards, George -
I do not recall where I have seen it. It was several years ago on an embedded compiler... seems like green hills or perhaps wind river. If you are using microsoft, I don't think you will have a problem treating foo and &foo as equals. Jim Fisher
Thanks all the same, Jim. regards, George