Original Post
if i define it as int table[32]; (there is a question, look at the title)
🔒 Locked
is &table[0] same as table
Advertisement
table would be an array, while &table[0] will return a pointer to an integer (a pointer to the first element of the array).
Difference between an array and a pointer.
I think the two are syntatically interchangable in most cases though.
Difference between an array and a pointer.
I think the two are syntatically interchangable in most cases though.
[WRONG]
I believe so.
"Table" is really the address of the first element so they are both equal.
[\WRONG]
I believe so.
"Table" is really the address of the first element so they are both equal.
[\WRONG]
Nope.
Table can be used to get the value of &table[0], so in a sense yes, but sizeof( table ) != sizeof( &table[0] ).
Also, the address value obtained from table == &table[0] meaning that they point to "the same address", yet are different types (int * and int (*)[32] ).
Table can be used to get the value of &table[0], so in a sense yes, but sizeof( table ) != sizeof( &table[0] ).
Also, the address value obtained from table == &table[0] meaning that they point to "the same address", yet are different types (int * and int (*)[32] ).
An additional subtlety arises when table is an object with an overloaded operator[](), such as a std::vector, std::string, std::deque, std::map, std::valarray or std::bitset; which, I agree, is not the case in your example.
This is particularly controversial in the case of std::vector
This is particularly controversial in the case of std::vector
Aren't they exactly the same thing? table is also the adress to the first element..
Quote:
Original post by password
Aren't they exactly the same thing? table is also the adress to the first element..
If you had bothered reading the other posts, you would know that isn't the case. table is an array of 32 integers in the example given, but can be used to get the address to the first element. This, however, doesn't mean table IS the address to the first element, because it isn't.
Yes and no, they both point to the same spot but are different types. The OP defined table as int table[32] so table's type is int * [32] while &table[0]'s type is int *. So basically using one instead of the other would cause the compiler to complain.
Quote:
Original post by Brother Bob Quote:
Original post by password
Aren't they exactly the same thing? table is also the adress to the first element..
If you had bothered reading the other posts, you would know that isn't the case. table is an array of 32 integers in the example given, but can be used to get the address to the first element. This, however, doesn't mean table IS the address to the first element, because it isn't.
I was talking about what I have read in a book myself, also I DID read the other posts so don't atleast tell me, what I did when you don't even know. I was merely pointing out that they had the same adress and that's a fact, the other was a question and the answer is that they are different types.
If you're going to correct me, and in an irascible way at that, do it right atleast..
Quote:
Original post by password
I was merely pointing out that they had the same adress and that's a fact, the other was a question and the answer is that they are different types.
The problem is that table itself doesn't have an address (try doing &table). It is not a variable: table[0], table[1]... are. However, table has a value, which is indeed the address of table[0].
Quote:
Original post by password
I was talking about what I have read in a book myself, also I DID read the other posts so don't atleast tell me, what I did when you don't even know. I was merely pointing out that they had the same adress and that's a fact, the other was a question and the answer is that they are different types.
If you're going to correct me, and in an irascible way at that, do it right atleast..
If you follow the thread you see a question, followed by a few answers with explanations that they are different in some sense and could be seen as thr same in some other sense. Then you come and say they are exactly the same, without explanation, contradicting what have already been said.
Given that context, it made me believe, rightfully in my oppinion, that you just hit the reply button and wrote a reply without thinking about what was already there.
The implicit conversion from array name to pointer to the first element of the array is a big source of confusion in general. As Fruny mentioned, the array name doesn't have an address, but it can be used to get one.
Quote:
Original post by rip-off
Also, the address value obtained from table == &table[0] meaning that they point to "the same address", yet are different types (int * and int (*)[32] ).
No, the operands of == are both the same type in that case. table yields a pointer to the first element for the == operation. Two int* are compared.
Quote:
Original post by TheFez6255
Yes and no, they both point to the same spot but are different types. The OP defined table as int table[32] so table's type is int * [32] while &table[0]'s type is int *. So basically using one instead of the other would cause the compiler to complain.
Its type is int[32], not int * [32] (the latter is an array of pointers to ints).
Quote:
Original post by Fruny Quote:
Original post by password
I was merely pointing out that they had the same adress and that's a fact, the other was a question and the answer is that they are different types.
The problem is that table itself doesn't have an address (try doing &table). It is not a variable: table[0], table[1]... are. However, table has a value, which is indeed the address of table[0].
Quote:
Original post by Brother Bob
As Fruny mentioned, the array name doesn't have an address, but it can be used to get one.
No, arrays have an address just like other types -- that's how you are able to make references and pointers to arrays. &table yields a int (*)[32] pointing to the array (pointer to an array of 32 ints). What's more is the "value" of table is not the address of the first element, it's just that a pointer to the first element can be yielded in cases where one is needed (think of it like a type with overloaded operator int*). The address of an array is guaranteed to point to the same location in memory as a pointer to the first element, however the datatypes are different -- the first is a pointer to an array of the appropriate size, the second is a pointer to the element type.
Edit: Holy moly lots of misinformation in this thread :|
[Edited by - Polymorphic OOP on April 25, 2006 4:47:44 PM]
Quote:
Original post by Polymorphic OOP Quote:
Original post by Brother Bob
As Fruny mentioned, the array name doesn't have an address, but it can be used to get one.
No, arrays have an address just like other types -- that's how you are able to make references and pointers to arrays.
You are in agreement. The array has an address. The array NAME does not. It *is* an address, but there is no chunk of memory (at least not one accessible to the programmer, unless he creates another one by making a pointer to the array beginning) storing the value corresponding to that address. It exists only in the mind of the compiler.
Quote:
Edit: Holy moly lots of misinformation in this thread :|
And misunderstanding. The semantics are maddeningly subtle. This is why std::vector and boost::array are your friends. (And at the very least, wrap things up in structs.)
Quote:
Original post by Zahlman
You are in agreement. The array has an address. The array NAME does not.
No, I'm afraid we disagree entirely. Going back to Fruny's post it is clear what he means:
Quote:
Original post by Fruny
The problem is that table itself doesn't have an address (try doing &table). It is not a variable: table[0], table[1]... are. However, table has a value, which is indeed the address of table[0].
Table in fact does have an address and &table is well defined. Here he doesn't differentiate between the array and the array name, as he shouldn't. The name of the array directly represents the array and is no different from the name of any variable, just like in the statement "float var;" you wouldn't differentiate between the var name and the variable itself. The only difference is that with arrays, the language allows for automatic conversion to a pointer to the first element if it is in the context where one is required, which is no different from a class with an overloaded operator int* or even the usual arithmetic conversions that take place such as when adding together two different arithmetic types.
Quote:
Original post by Zahlman
It *is* an address, but there is no chunk of memory (at least not one accessible to the programmer, unless he creates another one by making a pointer to the array beginning) storing the value corresponding to that address. It exists only in the mind of the compiler.
No. An array, or the array name if you prefer to call it that, is not, in any way, an address. An array is a contiguous block of N elements. The name refers to that block of memory just like any variable name refers to the variable it represents. There is no difference.
Edit: As an example relating it to the rest of the language:
void float_function( float& );void double_function( double );void array_function( int (&)[32] );void ptr_function( int* );int main(){ float float_var; float_function( float_var ); // float_var is passed by reference double_function( float_var ); // float_var is converted to double double double_var; float_var == double_var; // float_var is converted to double int array[32]; array_function( array ); // array is passed by reference ptr_function( array ); // array is converted to a pointer to the first element int* ptr; array == ptr; // array is converted to a pointer to the first element}The point of the above code is to stress that the float isn't a double simply because you can implicitly yield a double from it, just like the array is not a pointer because you can implicitly yield a pointer to the first element. What's more is the array name isn't an address just like the name of a float isn't a double. Just because an instance of a type "A" can be converted to another type "B" does not in any way mean that an instance of the type "A" is an instance of type "B", nor does it mean that the name of that instance is of type "B".
[Edited by - Polymorphic OOP on April 25, 2006 5:46:35 PM]
Quote:
Original post by Polymorphic OOP
Table in fact does have an address and &table is well defined.
My bad.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement