Just thinking, but could I get away with the claim that:
Given type array[10];
array is a type *const to the first element of the array? I would think this would address any potential l-value problems.
Just thinking, but could I get away with the claim that:
Given type array[10];
array is a type *const to the first element of the array? I would think this would address any potential l-value problems.
I'm afraid you couldn't get away with that claim either, eg,The type, int[], is different to int* const - While int[] may implicitly cast to int* const without problems, the opposite does not hold trueCode:template<int N>
void foo(int (&arr) [N] )
{
}
int main()
{
int bar[5];
foo( bar ); // ok
int* const blah = bar;
// foo( blah ) ; //error
}
On the other hand, a claim you might be able to get away with, could be that given a declaration, T array[10]; , that the type of 'array' is equivalent to T(&)[10] (Perhaps someone else would like to support or dismiss that claim)
That wasn't quite what I was getting at though. The main point, is that type information is the overriding factor. An array may implicitly cast to a pointer because it loses type information in the process, regarding the number of elements in the array. (information that a pointer isn't equipped to hold)
As a result, the pointer contains only the information regarding the first element. This is why an array type is not a pointer type.
You're just using the wrong terminology.
array is an l-value denoting the array.
&array[0] is an r-value denoting the address of the first element of the array.
Whenever array is converted to an r-value, the resulting r-value is the same as &array[0].
But value alone is an ambiguous term.
array == &array[0] is only true because the first term has been implicitly converted to an r-value.