Quote:
Originally Posted by psychopath
A pointer to the first element of the array is a pointer to the array itself.
m_vertex_array and &m_vertex_array[0] are equivalent statements.
Quote:
Originally Posted by psychopath
A pointer to the first element of the array is a pointer to the array itself.
m_vertex_array and &m_vertex_array[0] are equivalent statements.
Not true, even if some non-compliant compilers don't know the difference.Quote:
Originally Posted by AverageSoftware
Also not true. It depends on the context. m_vertex_array can be implicitly converted to a pointer to the first element, while &m_vertex_array[0] explicitly is a pointer to the first element.Quote:
m_vertex_array and &m_vertex_array[0] are equivalent statements.
I don't buy it.Quote:
Originally Posted by CornedBee
m_vertex_array[0] evaluates to *(m_vertex_array + 0)
&m_vertex_array[0] is therefore &*(m_vertex_array + 0)
The &* cancels out, leaving m_vertex_array + 0
m_vertex_array + 0 = m_vertex_array
Yes, but only in this context. Take, on the other hand, this:
Try uncommenting the two commented lines - it will fail. Try any other combination of the thing, it will fail. In particular, byref(four+0) will fail, thus proving that the equivalence you claim is not universal.Code:void byref(int (&args)[4])
{
std::cout << args[0] + args[1] + args[2] + args[3] << std::endl;
}
void byptr(int (*args)[4])
{
std::cout << (*args)[0] + (*args)[1] + (*args)[2] + (*args)[3] << std::endl;
}
int main()
{
int four[4] = { 1, 2, 3, 4 };
int three[3] = { 1, 2, 3 };
byref(four);
byptr(&four);
//byref(three);
//byptr(&three);
}
On some compilers, all calls to byptr might fail.
The thing is, array is NOT the same as &array[0]. The exact distinction lies with the differences between r-values and l-values, but the human-readable explanation is that array only decays to a pointer to its first element when needed.
See also 4.1 and 4.2 of the C++ standard. The first is normal l-value to r-value conversion, but it explicitly excludes arrays. The second says that when an r-value is needed but an array type l-value is provided, the r-value is the address of the first element of the array.
The first point I will concede, that an array is a pointer to its first element, I had forgotten about some of the exceptions that you later mentioned.
However, the statement that array is equivalent to &array[0] stands. If two things are equivalent, it means that they have the same value. I'm not sure what you're taking the word to mean, but it's not what I intended.
If "array" is an array, then *array is its first element, &array[0] is a pointer to its first element and &array is a pointer to the array. Thus he is correct to say that a pointer to the array is not the same as the array itself. Or in other words:Quote:
Originally Posted by AverageSoftware
&array[0] != &array
"pointer to first element" != "to pointer to array itself"
pointer to type array[0] != pointer to type pointer to type array[0]
I think you might have been confusing it with the idiom that "a pointer to the first element of an array is the array itself.", which is subtely different from "a pointer to the first element of the array is a pointer to the array itself", but means something else entirely.
I'm taking it to mean the same as you. I'm just disputing your universal claim that array and &array[0] have the same value, because it is simply not true. array can be, if the context requries it, converted to the same value as &array[0] is, but it is not inherently so.Quote:
Originally Posted by AverageSoftware
I think you have a different meaning of value then I do.Quote:
Originally Posted by CornedBee
The C/C++ standards define array[index] as *((array) + (index)). In the case where index is 0, this has the same value as *array.
That is to say, if you cout << array << " " << &array[0]; you will get the same value twice.
I think I've proven this mathematically above, I don't believe there's an exception, barring some crazy overloaded operator magic.
Just to see, I compiled this silly function down to assembly:
And got this:Code:void test()
{
int array[10];
if (array == &array[0])
{
array[0] = 1234;
}
else
{
array[0] = 5678;
}
}
GCC optimizes out the conditional, because the condition is provably true. The else branch doesn't even appear in the assembly output.Code:__Z4testv:
LFB2:
stmw r30,-8(r1)
LCFI0:
stwu r1,-96(r1)
LCFI1:
mr r30,r1
LCFI2:
li r0,1234
stw r0,24(r30)
lwz r1,0(r1)
lmw r30,-8(r1)
blr
This thread has been split from glDrawArrays().
Maybe where CornedBee has stated value, he means type; particularly in this context:
Insofar I think the times when CornedBee means a true assignable value, or when he is talking about the arrays not being an l-value is the source of confusion between the two of you. There is no secondary argument beyond where you've already conceded, and maybe I can explain.Quote:
I'm taking it to mean the same as you. I'm just disputing your universal claim that array and &array[0] have the same value, because it is simply not true. array can be, if the context requries it, converted to the same value as &array[0] is, but it is not inherently so.
True the C Standard defines what array[index] is supposed to do, and from what I see CornedBee does not dispute this.
When array is not an l-value, what array contains isn't going to be what changes, so &array[0] == array, or variants aren't going to prove anything new. Its type changes and dictates what you can and cannot do with the object. You just happen to luck out because, as of yet, whenever you try to test this concept, the array will be converted to a pointer, and array in that context becomes an l-value. What array contains will change in that context, and that impacts the logic of your examples.
That's the key difference, and it has less to do with hemming and hawing about what array "means" because as far as I can tell that's not the issue when it comes to array-type or non l-value variables.
I know you've conceded to this, but it bears repeating the type difference.
Code:int main( )
{
int array[3] = { 4, 5, 7 };
int *foo = &array[0];
array = foo; // can't assign? can't be equal either
return 0;
}
sizeof array
sizeof &array[0]
Are they always the same?
Values come from expressions. Assuming something like int array[10];, array is an expression. &array[0] is also an expression. These two expressions have the same value. I'm talking about numbers here, not types, not sizes, plain old numbers.
If this were not true, you could provide a counterexample in which array == &array[0] (also an expression) evaluates to false.
If you can do this, I will concede the point.
Show me an array that prints the second statement.Code:if (array == &array[0])
{
cout << "The expressions are equal.\";
}
else
{
cout << "The expressions are not equal.\n";
}
It's not a foo == bar problem. If foo == bar you have a compilable example. There are situations where array is not a pointer as CornedBee and I have demonstrated, and what array means will change. The difference is that the situations where array is used as an l-value where it isn't one do not compile; it is impossible to provide an example like the one you requested.
This is because you are arguing the wrong point. What I am asserting is a foo == bar problem.Quote:
Originally Posted by citizen
CornedBee's example is a type violation. It has nothing to do with values. If you force the issue with a reinterpret_cast, it works just fine. The last array element will be a garbage value, but that's a different problem.Quote:
There are situations where array is not a pointer as CornedBee and I have demonstrated, and what array means will change.
I'm not contending that. Once again, my assertion is that the expressions array and &array[0] have the same numeric value. Neither of these expressions produce an l-value, nor have I ever claimed that they do.Quote:
The difference is that the situations where array is used as an l-value where it isn't one do not compile
Then I consider my point established.Quote:
it is impossible to provide an example like the one you requested.
Oh, okay.
I apologize for misunderstanding then. As long as you understand the type difference, then there's no issue. Saying that &array[0] will always be the same as array is wrong, but they will always be the same object. That's ... apparent, actually.
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)
Quote:
Originally Posted by Bench82
I never claimed the opposite. If a then b does not imply if b then a.
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)Quote:
Originally Posted by AverageSoftware
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.