Am 22.04.2011 22:12, schrieb Paul:
I think I can safely assume that this is a lie.
and when I dereferenced this pointer, it did not access
the array.
Whatever that means when you say that *you* dereference this pointer...
Oh I get what you mean. You mean the value of the pointed to object is a
memory address. Well, it isn't. It only seems to be because anytime you
look at the value the implicit array-to-pointer conversion kicks in.
That does not mean that the real value of the object is a memory
address. For that, this memory address would have to be stored in the
object's memory. But an array does not store memory addresses.
Old gradpa "An array is not a pointer" is here again. You really really
should have heard of array-to-pointer decay by now.
You are either playing dumb just to keep the discussions going, or you
only pretended to understand, or you have a memory like a sieve.
If you access some object who's value whose value...
is the address of the array, you are
not accessing the array.
An array is not a pointer.
TO access the array you must access the data in the
array, not the data in another object.
That pointer you get from the implicit conversion is not an object
that's stored anywhere in memory.
Values? Plural values? No when you dereference a pointer there is only one
value, you cannot address arrays of objects.
Of course plural. It's an array. The values are all there in memory, one
after the other, starting at the address the pointer points to.
It doesn't it points to an array-type object. When its dereferenced it does
not access the array.
An object that has an array-type is, by definition, an array. If a
pointer has the type "pointer to array", then, by definition, it is a
pointer to an array.
When a pointer points to something , dereferencing it accesses the pointed
to entity, not some other entity..
Of course. And when you dereference a pointer to an array, you access
the array.
When you dereference a pointer you access what is pointed to.
Yes. When you dereference a pointer to an array, you get the array
itself. All of it at once. The whole array. That thing that contains 10
integers.
Accessing an array-type object, its not the same thing as accessing an array
of objects.
It is hard for you to think in abstractions. You cannot understand how a
pointer can point to all of an array at once. That's why you need to
think of an array object as an "identifier object", as some intermediate
strawman or proxy, that only yields the address of the first element.
You cannot understand that an array object *contains* its elements, but
that the array is also a single object in its own right. Even the
analogy to a structure did not seem to help, as far as I see from
glancing through that other thread... Poor Paul.
And with :
int arr[10] ={0};
int (*p)[10] =&arr;
/*dereferencing this accesses an object that holds the address of arr. */
No. That would mean there is a memory address stored in the memory
location that p points to. This is false.
Examine the object you get when you dereference it an you will see that it's
a memory address.
An array is not a pointer.
/*dereference it twice to access the array of integer objects*/
/*This is an indirect pointer to the array of integers*/
int a[3];
int *x = a;
int (*y)[3] =&a;
std::cout<< static_cast<void*>(x)<< std::endl
<< static_cast<void*>(y)<< std::endl;
The only difference is the type. Whereas with:
int* x;
int** y =&x;
the actual pointer values differ.
The difference is in levels of indirection, as I explained above.
Your two pointers x& y do not have the same level of indirection ,
regradless of their value.
Which pair of x&y? (I should have named them differently) Both actually
You cannot dereference 'y' to access three integer objects, Theoretically
dereferencing 'y' would access three integer objects, but it doesn't.
Not only in theory, but actually in practice, it does (the first y).
It does not access any integer object, because it is not type int*. You
cannot assign anything to it , because it does not access the integer
objects.
Same with an array object. This only means that you get the array when
you dereference a pointer to an array.
Dereferencing 'y' accesses an object that holds a memory address and it The second y, yes.
needs to be further dereferenced to access the array.
But you can only access a single int, not an array, after dereferencing it
twice.
This pointer points to an array-type identifier object, which is just
a
There is not such thing as an "identifier object". An identifier is a
compile-time entity, an object is a run-time entity. Using these two
terms
together makes no sense.
int arr[10];
'arr' is what I would consider an array type identifier object. My
That "identifier object" thing again. You think this is some kind of
intermediate strawman or something? It's the array itself. An object that
contains 10 subobjects. An object that lives in memory, has an address and
a size, where the size is the sum of all subobjects' sizes.
No an array-type object is not an object that contains sub-objects.
This is what you are unable to see. But that's how it is.
8.3.4 Arrays:
"An object of array type contains a contiguously
allocated non-empty set of N subobjects of type T."
terminology may not be correct as per standards but there you go , I've
explained what i mean.
pointer + some type info.
Dereferencing this pointer does not access the array, it gives the
address
of an array.
When you derefernece a pointer to int , you access an int object.
When you derefence a pointer to a vector, you access a vector object.
When you dereference a pointer to a T, you access a T.
When you dereference a pointer to int[3], you access an int[3].
No you don't. You need to dereference it twice.
If you do that, you go from "int (*)[3]" to "int[3]" to "int".
Yes that is how a pointer accesses a 2d array of ints.
We're strictly in 1d land here. No 2d arrays involved so far.
This is not an exception to the rule.
int a[3];
int (*p)[3] =&a;
a[1] = 1;
(*p)[1] = 1;
You dereference this pointer twice. Yes...
You have obviously tried to hide this
fact behind the subscript syntax.
No, because I do the same with "a". After dereferencing p by writing (*p),
I'm at a level of indirection that is the same as "a" itself. I
demonstrate this by applying the same subscript to both, accessing the
same element of the array.
So why did you present it as an example that only dereferenced it once?
Because the point was that the first dereference yields something
equivalent to the array itself. The subscriptions only serve to show
that the levels of indirection are the same.
But, actually, as you deny the fact that "a" is an array, the example
fails to prove my point.
Good.
but 'a' is an object that already points to the array.
"a" is an array. An array is not a pointer.
No 'a' is defined in the standard to be an array-type identifier.
"a" is an identifier that identifies an object of array type, because
Section 8.3 defines that a declarator is the combination of an
identifier and a type, and Section 8 defines that a declarator declares
an object. So "a" is an (identifier that names an) "object of array
type" and thus *is* an array.
To you, of course, only the sequence of elements in memory is an array.
All that identifier and pointer stuff is just the formal hullabaloo on
top that nobody needs to understand, but which enables you to eventually
access the elements, which is all you care about.
It is not modifiable, if 'a' was the array itself that would suggest that
all arrays are non modifiable.
Actually, an array is non-modifiable and non-copyable. Only its elements
are.
You don't , you get a pointer to array TYPE. When you dereference this
pointer you do not access the array because it does not directly point to
the array.
Actually, "accessing an array" does not have much value, because
ultimately you can only access its elements. But the level of
indirection after dereferencing a pointer to array is that of the array
itself.
It is an array-type object, which is a non modifiable object.
And its value is that of a memory address.
Array-to-pointer decay.
From the standards 8.3.4 Arrays:
"then the type of the identifier of D is an array type."
An identifier identifies an object. It is not an object itself.
Identifier is a compile-time entity, object is a runtime entity.
An object can have an identifier that constitutes the name of the object.
So the identifier is an array-type.
Not "is". An identifier "has" an array type. An identifier, and the
object it names, has a type. That type can be an array type.
Whether or not it's correct to say its
an array-type identifier object is very pedantic. I had already explained
what I meant by this.
By thinking of an "identifier object" you introduce an intermediate
level of reference which isn't there.
Peter
