Well defined meaning of pointer to an array

[Joshua Maurice]

I hope I didn't yet, at least that wasn't my intention. And I also
think this discussion is over now. You're right, Paul seems not to
be inclined to really argue, at least not for long.

Oh, don't worry about it. I think I was just trying to be playful...
is perhaps the best term? I sincerely hope that no one is actually
anything more than slightly annoyed to see someone replying to Paul.
At least, I'm not.

 

[Paul]

I think I can safely assume that this is a lie.

Why would it even cross your mind that that is a lie?

Whatever that means when you say that *you* dereference this pointer...

Yes whatever that means.

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.

Replying to yourself ^^^^^^
Yeah yeah an array is not a pointer.

An array is not a pointer. So you keep saying.

That pointer you get from the implicit conversion is not an object that's
stored anywhere in memory.

Where is this object stored? USB stick? CDRom?

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.

No you said :
"A pointer-type object stores memory addresses as their value. There is no
memory address contained in the bytes of the object we reached.
What's in there are the values of the actual array elements"

So what type are you talking about that stores values of array elements?

An object that has an array-type is, by definition, an array.

No its not, by definition its an array-type object and it's non modifiable.
An array is a contiguous sequence of objects of element-type, and it is
modifiable.

If a pointer has the type "pointer to array", then, by definition, it is a
pointer to an array.

A pointer to an array-type is a pointer to a non modifiable array-type
object.
A pointer to an array of objects is a pointer to a modifiable array of
objects.

You do not acknoweldge these different pointer types, which seems to suggest
you are either ignorant or you lack knowledge about the C++ language.

Of course. And when you dereference a pointer to an array, you access the
array.

Yes like so:
int* p = new int[64];
*p = 1; /*Accessing the array*/
p[5] = 6; /*Another way to derefernece the pointer*/

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.

No, you cannot access a whole array at once, unless its size one or some
other silly example.

It is hard for you to think in abstractions. You cannot understand how a
pointer can point to all of an array at once.

Yes I can, a char* can point to a single char or an array of chars. You are
the one who cannot understand this.

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.

A struct is not an array

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. So you've been saying.

/*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.

No an array object is not the same, you can dereference an array object to
access the 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."

No thats describing a object of array type , not an array-type object.

An array-type object is the following 'arr' object:
int arr[500];

An object of array type, is a region of storage such as an array of integer
objects.

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.

What exactly is something equivalent to the array itself?

But, actually, as you deny the fact that "a" is an array, the example
fails to prove my point.

I don't deny the fact that 'a' is an array.
But more accurately 'a' is an array-type.
'a' is not an array in the same context , that it's a sequence of objects.

"a" is an array. An array is not a pointer. SO you keep saying.

"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.

More accurately 'a' is an array-type identifier.

To you, of course, only the sequence of elements in memory is an array.

Nonsese it is you who have the narrow minded view here , not I.

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.

Actually, an array is non-modifiable and non-copyable. Only its elements
are.

Yes because you cannot access an array as a whole. You can only reference
it.
And the only way to reference it is with a pointer to one if its elements,
usually the first element.

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.

Yes you can only access its elements , because that is what an array is, a
sequence of elements.
So therefore a pointer to an array is a pointer to its elements.

Array-to-pointer decay.

Which shows that in this situation the array-type object is simply treated
as a pointer.

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.

its an identifier of array-type , but its not an object?

So if we take the address of this identifier, what are we taking the address
of:
The address of an identifier , or the address of an object.?

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.

The standard says "is":
"the type of the identifier of D is an array type"

By thinking of an "identifier object" you introduce an intermediate level
of reference which isn't there.

But there is a level of reference there. An array identifier needs to be
dereferenced to access an array.

 

[Peter Remmers]

Am 23.04.2011 02:52, schrieb Paul:

Why would it even cross your mind that that is a lie?

Because I know that you know what it prints. You don't need to actually
run it.

Replying to yourself ^^^^^^
Yeah yeah an array is not a pointer.

I reapeat that for every misconception of yours that is ultimately due
to your failure to understand that an array is not a pointer.

Where is this object stored? USB stick? CDRom?

Nowhere. That's my point. It's an rvalue, not an lvalue. It is not
stored in memory, more specifically: it's not stored in the memory the
array occupies, and there's also no intermediate "identifier object"
that stores this pointer value.

No you said :
"A pointer-type object stores memory addresses as their value. There is no
memory address contained in the bytes of the object we reached.
What's in there are the values of the actual array elements"

So what type are you talking about that stores values of array elements?

You already acknowledged that the pointer values of

arr
&arr
&arr[0]

are all the same.

That means there cannot be any memory address stored at *&arr.

No its not, by definition its an array-type object and it's non modifiable.

See below on "object of array type" vs. "array-type object".

An array is a contiguous sequence of objects of element-type, and it is
modifiable.

I'll quote you on that.

A pointer to an array-type is a pointer to a non modifiable array-type
object.
A pointer to an array of objects is a pointer to a modifiable array of
objects.

You do not acknoweldge these different pointer types, which seems to suggest
you are either ignorant or you lack knowledge about the C++ language.

This is all due to your non-standard use of the term "array".

You are making an off-by-one error concerning level of indirection.

C++ standard | Paul
--------------------------+-----------------------------
sequence of elements | array
array | array-type object
pointer to array | pointer to array-type object
pointer to element | pointer to array

Of course. And when you dereference a pointer to an array, you access the
array.

Yes like so:
int* p = new int[64];

That's not a pointer to an array....

*p = 1; /*Accessing the array*/

Accessing an element of the array...

p[5] = 6; /*Another way to derefernece the pointer*/

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.

No, you cannot access a whole array at once, unless its size one or some
other silly example.

As I said. You cannot directly access an array, you can only access its
elements. But the level of indirection is the same as the array when you
dereference a pointer to the array.

Yes I can, a char* can point to a single char or an array of chars. You are
the one who cannot understand this.

Ok then. What you fail to understand is how an array can be a single
object in its own right.

A struct is not an array

But a struct is a singular object that has subobjects. And that is
exactly the same with an array. That's why a struct is a valid analogy.

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.

So you've been saying.

I reapeat that for every misconception of yours that is ultimately due
to your failure to understand that 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.

No an array object is not the same, you can dereference an array object to
access the array.

You can dereference (*y) again to access the array elements, just like
you can with the array "a" itself.

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."

No thats describing a object of array type , not an array-type object.

Are you seriously arguing that "object of array type" is not the same as
"array-type object"?

You are really hopeless.

But wait, I already knew that.

An array-type object is the following 'arr' object:
int arr[500];

arr is an object. That object has a type. That type is an array type.
Therefore arr is an object of array type. Therefore it is an array.
Therefore it has elements. Those elements are subobjects.

Therefore arr is an object of array type that contains a contiguously
allocated non-empty set of 500 subobjects of type int.

There is no use arguing when you refuse to acknowledge the most basic
things.

An object of array type, is a region of storage such as an array of integer
objects.

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.

What exactly is something equivalent to the array itself?

It's equivalent because you can substitute "(*p)" anywhere you can use "a".

But to you, "a" is not the array itself.

I don't deny the fact that 'a' is an array.
But more accurately 'a' is an array-type.

'a' is not an array in the same context , that it's a sequence of objects.

You contradict yourself.
Either you claim that an "array-type object" is not an array, and stand
by that POV, or you acknowledge that "a" *is* an array.

If you change position every time it suits you, you can't be taken
seriously.

But wait, I already knew you do that.

SO you keep saying.

I reapeat that for every misconception of yours that is ultimately due
to your failure to understand that an array is not a pointer.

More accurately 'a' is an array-type identifier.

Nonsese it is you who have the narrow minded view here , not I.

It must be, or else your refusal to acknowledge that "a" is an array
does not make sense.

If you say that "a is an array" is false, and you also say that "only
the sequence in memory is an array" is also false, then

to you, *what* exactly *is* an array??

No wonder it's no good communicating with you, if the word "array" rings
different bells at different times in your head, and no one can predict,
which. Are you doing that on purpose?

Yes because you cannot access an array as a whole. You can only reference
it. Yes.
And the only way to reference it is with a pointer to one if its elements,
usually the first element.

You can of course reference an array with a pointer to the array. It's
simple.

Yes you can only access its elements , because that is what an array is, a
sequence of elements.
So therefore a pointer to an array is a pointer to its elements.

By value, yes. By type, no.

Which shows that in this situation the array-type object is simply treated
as a pointer.

The automatic conversion kicks in at about every opportunity, because
without it, there's not much you can do with the array.
But that does not mean the array object stores a pointer value.

its an identifier of array-type , but its not an object?

An identifier is a label. An object can have a label. An object is not
equivalent to its label.

The label says "This object is named 'arr'. Its type is 'int[3]'".

So if we take the address of this identifier, what are we taking the address
of:
The address of an identifier , or the address of an object.?

You can't take the address of an identifier. It's only syntax. If you
write "&arr", you take the address of the object named "arr", because
you have to somehow refer to the object. That's what names are for.

The standard says "is":
"the type of the identifier of D is an array type"

The standard says:
The type is a type.
The type is an array type.
The type of the identifier is an array type.
The type of the identifier of D is an array type.

It does not say:
The identifier is an array type.

Dude, that's basic english. That's not even got anything to do with C++.

If you can't read, then there's no point in arguing with you.

But wait, I already knew this.

But there is a level of reference there. An array identifier needs to be
dereferenced to access an array.

That's because it has subobjects. You have to somehow express which of
the subobjects you want to access.
With a struct, where the subobjects have names, you can just use the "."
operator and refer to the subobject via its name.
With an array, all subobjects are anonymous, sou you have to use pointer
arithmetics to address them.

An array object and a struct object are at the same level of
indirection. A pointer to a struct and a pointer to an array object are
at the same level of indirection. A pointer to an element of the array
is at a different level of indirection.

Peter

 

[Paul]

Am 23.04.2011 02:52, schrieb Paul:
Because I know that you know what it prints. You don't need to actually
run it.

Why would it cross your mind its a lie?

I reapeat that for every misconception of yours that is ultimately due to
your failure to understand that an array is not a pointer.

So you keep saying. But you don't understand what an array is so I'd expect
those kinds of repetative statements from you.

It must be stored someplace or it doesn't exist. Let me put it another way,
where is the data that represents this value stored?

Nowhere. That's my point. It's an rvalue, not an lvalue. It is not stored
in memory, more specifically: it's not stored in the memory the array
occupies, and there's also no intermediate "identifier object" that stores
this pointer value.

It is a value and its stored someplace in memory. So where is it stored?

Do we just magically create a pointer to an array? And pick any address?

No you said :
"A pointer-type object stores memory addresses as their value. There is
no
memory address contained in the bytes of the object we reached.
What's in there are the values of the actual array elements"

So what type are you talking about that stores values of array elements?

You already acknowledged that the pointer values of

arr
&arr
&arr[0]

are all the same.

That means there cannot be any memory address stored at *&arr.

I have already said this and now you are just copying exactly what i said
but interpreting it incorrectly.
You are just a pedantic nitpicking fool who cannot accept that an int* can
point to an array of ints.
You are fundamentally wrong and I don't intend to play your nitpicking
twisted words games any longer , I have better things to do than to argue
with someone who I know if fundamentally wrong.

If you cannot understand that an int* can pointer to an array of integers
then, all I can say is go awway and study some more.


<snip irritating pedantic word games>

 

[Peter Remmers]

Am 23.04.2011 13:46, schrieb Paul:

It must be stored someplace or it doesn't exist. Let me put it another way,
where is the data that represents this value stored?



It is a value and its stored someplace in memory. So where is it stored?

Do we just magically create a pointer to an array?

Not magically, but yes. In the same way you create a pointer to any
other object. You use the address-of operator and get the address. But
of course that does not mean that the address is stored in the object
itself.

int x;
int *y = &x;

x is just a simple integer. Where has the address of x been stored
before it has been assigned to y? Surely not "in x".

Only a pointer object stores a pointer value, i.e. a memory address. An
array is not a pointer and does not store a memory address.

And pick any address?

Of course not.

You already acknowledged that the pointer values of

arr
&arr
&arr[0]

are all the same.

That means there cannot be any memory address stored at *&arr.

I have already said this and now you are just copying exactly what i said
but interpreting it incorrectly.

If there is an int at the memory location of "&arr[0]", then at the same
memory location, addressed by "&arr", and at the same time, there cannot
also be stored a pointer value.

You are just a pedantic nitpicking fool who cannot accept that an int* can
point to an array of ints.

You are fundamentally wrong and I don't intend to play your nitpicking
twisted words games any longer , I have better things to do than to argue
with someone who I know if fundamentally wrong.

If you cannot understand that an int* can pointer to an array of integers
then, all I can say is go awway and study some more.

That is not what we are arguing about right now.

<snip irritating pedantic word games>

That's Paul for you.

Honestly, if you don't care, and don't read what someone else took the
effort of writing, and just snip it and dismiss it as "pedantic word
games", then you are wasting people's time.

On the other hand, I'm amazed at your endurance. In the beginning it
only took a few posts until you pulled your insult gun. At least in that
regard you are showing some progress.


Personally, I'm not really trying to convince you. I'm just honing my
arguing skills. It's a good practice. And to have someone who's almost
always willing to be a sparring partner, for free, is pretty handy.
I guess I should be crying now and run to mama, because you don't want
to play with me anymore.
Hm, but I'm not.

Peter

 

[Paul]

Am 23.04.2011 13:46, schrieb Paul:
Not magically, but yes. In the same way you create a pointer to any other
object. You use the address-of operator and get the address. But of course
that does not mean that the address is stored in the object itself.

int x;
int *y = &x;

x is just a simple integer. Where has the address of x been stored before
it has been assigned to y? Surely not "in x".

Only a pointer object stores a pointer value, i.e. a memory address. An
array is not a pointer and does not store a memory address.

Almost any type of object of the correct size can store a pointer value. Its
just an integer value.

So where does &x get the value that is the address of x?
Obviously there must be an object someplace that holds this value.

And pick any address?

Of course not.

You already acknowledged that the pointer values of

arr
&arr
&arr[0]

are all the same.

That means there cannot be any memory address stored at *&arr.

I have already said this and now you are just copying exactly what i said
but interpreting it incorrectly.

If there is an int at the memory location of "&arr[0]", then at the same
memory location, addressed by "&arr", and at the same time, there cannot
also be stored a pointer value.

There is no pointer values stored in the array. An array of integers
consists of ...*drumroll*... integer objects, its not some fancy pointer
object.
There is however some fancy pointer, under the hood someplace, which is used
by the compiler to index the array.

That is not what we are arguing about right now.



That's Paul for you.

Honestly, if you don't care, and don't read what someone else took the
effort of writing, and just snip it and dismiss it as "pedantic word
games", then you are wasting people's time.

I dont have time to spend hours playing silly word games, I would perhaps
have more time to spend playing silly word games if you were able to who
could even acknowledge the differnece in concepts I have epxlained. But you
cannot even acknoweldge that the following are different concepts:
a) an array of integer objects
b) an object of array-type

If you do not understand the difference then there is no point in wasting
any more time talking to you about it, all you are doing is wasting my time
playing some twisted words games, and thats not my thing.

On the other hand, I'm amazed at your endurance. In the beginning it only
took a few posts until you pulled your insult gun. At least in that regard
you are showing some progress.


Personally, I'm not really trying to convince you. I'm just honing my
arguing skills.

Your not doing a very good job , because you seem to be practising how to
lose an argument.

A pointer to an array of T's is a pointer of type T that can access any of
the T-type array element.

You say that a pointer to an array of T's cannot be a pointer of type T*,
because this pointer does not point to a whole array at once. But it doesn't
need to point to the whole array at once to point to the array.
A pointer, that points to a whole array at once, is only a pointer dressed
up to represent this concept and it's techincally impossible to access a
whole array at once.

It's a good practice. And to have someone who's almost always willing to
be a sparring partner, for free, is pretty handy.
I guess I should be crying now and run to mama, because you don't want to
play with me anymore.
Hm, but I'm not.

If you are happy to blurt nonsense across the internet, in what you describe
as sparring practise, that up to you.
Its you who is going to look dumb to anyone who understands the discussion,
because your agument is fundamentally wrong, no matter how many times you
correct my terminolgy or manage to wangle a point or or two back with silly
words games and twisted interpretations.