5 ms·

Quite right. A set of interesting equalities: (void)&array == (void)&array[0] // likely true (void)&pointer == (void)&pointer[0] // likely fal

Quite right. A set of interesting equalities: (void*)&array == (void*)&array[0] // likely true (void*)&pointer == (void*)&pointer[0] // likely false (although it could be true by coincidence) A pointer to an array is the address of the first element. The name of an array can be trivially and implicitly converted to the address to it's first element, but this conversion creates a (temporary) pointer, it does not make the array itself a pointer! The array (nor it name) is not in and of itself storage for any such address, it is no pointer, and as a result &array won't give you back a pointer-to-pointer because there's no underlying 4-8 byte storage for the underlying pointer - there's no permanent pointer to point to.

kazinator 12y ago
Sure: (void*)&array == (void*)&array[0] // likely true That is true by definition. The address of the first element is the same as that of the array, period. They cannot convert to different void pointers.
- pqomdv 12y ago
  Which definition is that? You probably though of: array == &array[0] which is always true. This: (void*)&array == (void*)&array[0] which simplifies to: (void*)&array == (void*)array is not. C doesn't guarantee that the values of &array and array are the same. The types T( * )[ * ] and T* are not even compatible and those two pointers are allowed to have different sizes and representation.
  - kazinator 12y ago
    The first element of an array is located at the address of an array. Even if the pointer-to-array and pointer-to-element types have different size and representation, they point to the same place. The resulting pointer-to-void converted values must point to that place, and have the same type. This relationship is also true between a pointer to a struct and a pointer to the first element. And also among pointers to the elements of a union.
- MaulingMonkey 12y ago
  Granted, we've been presupposing C, but: In C++ you have a simple out by overloading T::operator&, allowing you to alter the result of the RHS of that equation and break it. There's also a little bit in the standard prohibiting comparing pointers to different arrays - a leftover from the 16-bit era of near and far pointers I suspect - but that appears to only apply to relational comparisons in the C++11 standard: http://stackoverflow.com/questions/9086372/how-to-compare-pointers/9086675#9086675 http://stackoverflow.com/questions/9086372/how-to-compare-po... I either misremember this applying to == and != as well (likely), or this changed since the C++03 standard that I'm used to referencing (unlikely). I'm also unsure if C has an equivalent rule. A fun note from that SO link: std::less<T*> guarantees more than operator<( T*, T* ) enabling std::map<T*,...> et all. (edit: formatting)
arielby 12y ago
According to the C FAQ, Whenever an array appears in an expression, the compiler implicitly generates a pointer to the array's first element, just as if the programmer had written &a[0]. The exceptions are when the array is the operand of a sizeof or & operator, or is a string literal initializer for a character array.

Quite right. A set of interesting equalities: (void*)&array == (void*)&array[0] // likely true (void*)&pointer == (void*)&pointer[0] // likely fal

kazinator 12y ago

Sure: (void*)&array == (void*)&array[0] // likely true That is true by definition. The address of the first element is the same as that of the array, period. They cannot convert to different void pointers.

pqomdv 12y ago
Which definition is that? You probably though of: array == &array[0] which is always true. This: (void*)&array == (void*)&array[0] which simplifies to: (void*)&array == (void*)array is not. C doesn't guarantee that the values of &array and array are the same. The types T( * )[ * ] and T* are not even compatible and those two pointers are allowed to have different sizes and representation.
- kazinator 12y ago
  The first element of an array is located at the address of an array. Even if the pointer-to-array and pointer-to-element types have different size and representation, they point to the same place. The resulting pointer-to-void converted values must point to that place, and have the same type. This relationship is also true between a pointer to a struct and a pointer to the first element. And also among pointers to the elements of a union.
MaulingMonkey 12y ago
Granted, we've been presupposing C, but: In C++ you have a simple out by overloading T::operator&, allowing you to alter the result of the RHS of that equation and break it. There's also a little bit in the standard prohibiting comparing pointers to different arrays - a leftover from the 16-bit era of near and far pointers I suspect - but that appears to only apply to relational comparisons in the C++11 standard: http://stackoverflow.com/questions/9086372/how-to-compare-pointers/9086675#9086675 http://stackoverflow.com/questions/9086372/how-to-compare-po... I either misremember this applying to == and != as well (likely), or this changed since the C++03 standard that I'm used to referencing (unlikely). I'm also unsure if C has an equivalent rule. A fun note from that SO link: std::less<T*> guarantees more than operator<( T*, T* ) enabling std::map<T*,...> et all. (edit: formatting)

arielby 12y ago

According to the C FAQ, Whenever an array appears in an expression, the compiler implicitly generates a pointer to the array's first element, just as if the programmer had written &a[0]. The exceptions are when the array is the operand of a sizeof or & operator, or is a string literal initializer for a character array.