The poster probably did not help matters after that by calling the downvoters "clueless n00bs" or making a self-righteous statement about how they won't delete the comment just because of downvotes. That kind of toxic behavior just ensures that you'll get more downvotes.
Nope; I simply refuse to delete a comment that is civil and correct just because of some fluffy downvotes. It stays and that's that.
For instance, this equivalence is not required:
(sizeof array) == (sizeof &array[0])
If array were the address of the first element, then it would always have the same size. Be careful with words like "is".
Oh, the above is "in C", by the way. We wouldn't want not to satisfy your key point!
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)
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.
(void*)&array == (void*)&array[0] // likely true
You probably though of:
array == &array[0]
This:
(void*)&array == (void*)&array[0]
(void*)&array == (void*)array
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.
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.
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-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*>
operator<( T*, T* )
std::map<T*,...>
(edit: formatting)
Arrays are aggregates of contiguously allocated objects.
Pointers are values indicating the storage locations of objects.
Thus, not equivalent.
Pointers are involved when you access an array. That doesn't make it an array. Just like scanning written text on a piece of paper using your index finger does not mean that "paper" and "your index finger" are equivalent. That's true even if you always instantiate an index finger before evaluating a piece of paper: co-ocurrence is not equivalence.