Well defined meaning of pointer to an array

T

TJorgenson

Hi Jens Thoms Toerring,

I have been reading this newsgroup for many years and you are by far
the most patient poster I have ever read given the disrespectful
responses that you receive. I have enjoyed reading your posts in this
thread and your in-depth explanations of what the C++ standard
defines. Like everyone else in this newsgroup (-1), I accept that an
array is itself an object, but this fact is often obscured in real
code by the “special rules” concerning arrays (i.e. can’t pass by
value, decaying to pointer when a value is needed, etc). You brought
much clarity to this discussion when you introduced the actual meaning
of “pointer to array” as:

char (*p64)[64];

Your posts got me thinking about the inability to pass arrays by
value, which made me curious about how one interprets the following
code...

struct A
{
int a[25];
};

void foo()
{
A x = {};
A y = {};
x = y; // Does this actually copy an array by value?
}

According to the standard, is the array above, wrapped in a struct,
actually copied by value, or is there another way the C++ standard
describes this behavior? How does member-wise copy apply to array
members?

Thanks again for your thoughtful posts,
Tony
 
P

Paul

Hi Jens Thoms Toerring,

I have been reading this newsgroup for many years and you are by far
the most patient poster I have ever read given the disrespectful
responses that you receive. I have enjoyed reading your posts in this
thread and your in-depth explanations of what the C++ standard
defines. Like everyone else in this newsgroup (-1), I accept that an
array is itself an object
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

You are obviously pretty stupid, in fact you are a total fuckin arsehole who
is doing nothing more than disrespecting me for no reason, I don't care if
you support the other argument , it gives you no right to disrepect me.

Anyway dickhead. you are obviously a total fucking mong because an array is
not AN object unless it is size one, An array is a sequnece of objects you
fuckin moronic idiot.
 
I

Ian Collins

Hi Jens Thoms Toerring,

I have been reading this newsgroup for many years and you are by far
the most patient poster I have ever read given the disrespectful
responses that you receive.

Very true, quite remarkable in fact!
I have enjoyed reading your posts in this
thread and your in-depth explanations of what the C++ standard
defines. Like everyone else in this newsgroup (-1), I accept that an
array is itself an object, but this fact is often obscured in real
code by the “special rules” concerning arrays (i.e. can’t pass by
value, decaying to pointer when a value is needed, etc). You brought
much clarity to this discussion when you introduced the actual meaning
of “pointer to array” as:

char (*p64)[64];

Your posts got me thinking about the inability to pass arrays by
value, which made me curious about how one interprets the following
code...

struct A
{
int a[25];
};

void foo()
{
A x = {};
A y = {};
x = y; // Does this actually copy an array by value?
}

According to the standard, is the array above, wrapped in a struct,
actually copied by value, or is there another way the C++ standard
describes this behavior? How does member-wise copy apply to array
members?

Nesting an array in a struct is a common C trick used for copying (any
therefore passing by value) arrays. Why the trick is necessary goes way
back into the history of C.
 
I

Ian Collins

Yeah I was right you are becoming a total arse now.

Ah, he finally shows is true colours.
I'm hiding behind nothing, if you don't understand a simple term like
"references" you must be a bit stupid.

Now we know he has run out of silly ideas.
 
I

Ian Collins

Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that is the
array.
This pointer points to an array-type identifier object, which is just a
pointer + some type info.

So I ask again, please cite section(s) of the standard that specifies
this mysterious "pointer + some type info" type.
 
P

Paul

Ian Collins said:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that is
the
array.
This pointer points to an array-type identifier object, which is just a
pointer + some type info.

So I ask again, please cite section(s) of the standard that specifies this
mysterious "pointer + some type info" type.

--
Piss off ya fuckin idiot.
 
J

Jens Thoms Toerring

Paul said:
An array is not a single object its an *drumroll* array of objects.
If you dont understand that perhaps you will understand the term it is a
contiguous sequence of objects.

Thank you, but I think I understand what an array is. And in
contrast to some other people, not be named here, I even un-
derstand that an array not only contains objects but *drum-
roll* also is an object in its own right;-)
There is no containing object that contains the array elements. An array is
accessed by dereferencing a pointer, oh wait you don't understand the term
accessed do you. Ok if you cannot understand. I cannot communicate with you.

Oh, are we back to name-calling just because I ask for a some-
what more precise definition of terms you're using since you
sometimes have a bit of a humpty-dumpty-ish way with words?
What a pity...
I think if you cannot understand terms like "accessing an array" and
"referencing an array" then you are maybe not intelligent enough for a
conversation at this level.

Well, then let's stop here. Have a nice day.
 
P

Peter Remmers

Am 22.04.2011 02:56, schrieb Paul:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that is the
array.
Regarding the pointer value, it does:

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

This is not an exception to the rule.

int a[3];
int (*p)[3] = &a;

a[1] = 1;
(*p)[1] = 1;

"*p" is equivalent to "a"
How is it when dereferencing the above pointer it does not access the array?
Because its not a pointer to THE array. Its a pointer to an array-type
identifier object with the name 'arr'.

Peter
 
J

Jens Thoms Toerring

Joshua Maurice said:
Seriously Jens Thoms Toerring, I would appreciate your efforts if it
was targeted at someone genuinely willing to listen and learn, but
Paul has demonstrated over the past few months (?, a long time at
least), that he refuses to adopt the language of discourse of the
super majority.

Well, he was in my killfile for some time (and has a good chance
of going back there;-) but I felt like giving it a try anyway.
And until recently he stayed more or less polite for once, at
least to me...
You're welcome to continue arguing with him if only
because I have no particular power nor moral justification for
stopping you, but you should be aware that this will go nowhere, and
just possibly irritate the rest of us.

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.
Man, I really need to get a real newsreader so I can plonk people. Oh
procrastination.

I've found having a well-kept killfile contributes a lot to a
positive usenet experience;-)
Best regards, Jens
 
J

Jens Thoms Toerring

TJorgenson said:
Your posts got me thinking about the inability to pass arrays by
value, which made me curious about how one interprets the following
code...
struct A
{
int a[25];
};
void foo()
{
A x = {};
A y = {};
x = y; // Does this actually copy an array by value?
}
According to the standard, is the array above, wrapped in a struct,
actually copied by value, or is there another way the C++ standard
describes this behavior? How does member-wise copy apply to array
members?

Nothing of interest I could add to what Ian Collins already
wrote. So just yes, they opened up a 'loophole' when they
introduced structures in C having values that can be passed
around or assigned. Sometimes useful in C but, of course, C++
has much better ways to achieve the same effects with vectors.

Best regards, Jens
 
P

Paul

Jens Thoms Toerring said:
Thank you, but I think I understand what an array is. And in
contrast to some other people, not be named here, I even un-
derstand that an array not only contains objects but *drum-
roll* also is an object in its own right;-)

But you clearly do not understand what an array is. An array is a contiguous
sequence of objects, an array is not a container object.
Even if we go along with your misinterpretation of an array of objects, to
mean an array identifier object it would still be incorrect to say this
object contained the array elements.
Oh, are we back to name-calling just because I ask for a some-
what more precise definition of terms you're using since you
sometimes have a bit of a humpty-dumpty-ish way with words?
What a pity...

I use the term accessing an object when I speak about dereferencing a
pointer to the object.
You would say that dereferencing an pointer to an object "returns" an
object, which I find to be inaccurate because in the following dereferencing
expression nothing is returned:

int* p= new int[5];
*p = 1;

The term "return" is ok when speaking about a memory read expression, but it
does not fit for a write expression. Therefore it is not suitable as a
general term to express what happens when we dereference a pointer, the term
"accesses" is more suitable.

Well, then let's stop here. Have a nice day.
Same to you.
 
P

Paul

Peter Remmers said:
Am 22.04.2011 02:56, schrieb Paul:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that is
the
array.
Regarding the pointer value, it does:
No it doesn't.
If you access an object in memory by means of dereferencing a pointer, the
accessed object is what the pointer is pointing to.

When you dereference the pointer 'p' above you access the object in memory
that 'p' points to. If you examine this pointed to object you will find it
has a memory address value. You have not accessed the array of integers, you
have accesssed another pointer-type object.
Therefore this pointer can only be said to indirectly point to an array of
integers, in the same way a pointer to pointer to int indirectly points to
an int for example:

int x;
int* p= &x;
/*This pointer points to an int*/
/*When dereferenced you access the int object*/

int** pp = &p;
/* This pointer points to a pointer to int.*/
/*When dereferenced you access another pointer object*/
/*This is an indirect pointer to int because its needs to be dereferenced
twice to access the int object*/

And with :
int arr[10] ={0};
int (*p)[10] = &arr;
/*dereferencing this accesses an object that holds the address of arr. */
/*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.

You cannot dereference 'y' to access three integer objects, Theoretically
dereferencing 'y' would access three integer objects, but it doesn't.
Dereferencing 'y' accesses an object that holds a memory address and it
needs to be further dereferenced to access the array.
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
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.
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. You have obviously tried to hide this
fact behind the subscript syntax.
"*p" is equivalent to "a"

Yes but 'a' is an object that already points to the array.
But when we take the address of 'a' we are creating a pointer to something
that already points to the array.
This is why we need to dereference such a pointer twice to access the array.
 
P

Paul

Leigh Johnston said:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that
is the
array.
Regarding the pointer value, it does:
No it doesn't.
If you access an object in memory by means of dereferencing a pointer,
the accessed object is what the pointer is pointing to.

When you dereference the pointer 'p' above you access the object in
memory that 'p' points to. If you examine this pointed to object you
will find it has a memory address value. You have not accessed the array
of integers, you have accesssed another pointer-type object.
Therefore this pointer can only be said to indirectly point to an array
of integers, in the same way a pointer to pointer to int indirectly
points to an int for example:

Your understanding of pointers to arrays is wrong.

An array is not a "pointer-type object"; an array is an array, period, and
dereferencing the pointer-to-array 'p' above results in a reference to the
array *not* a pointer. The result of dereferencing 'p' you will find the
array not some "memory address value" as Peter Remmers demonstrated (but
which you chose to ignore). You attempted to prove otherwise yesterday by
but failed to do so as what you were actually doing was simply invoking
the standard array-to-pointer conversion.
No your understanding is wrong.
The following array can be seen in two different contexts
int arr[22];

a) An array of integer objects
b) The object 'arr' which points to the array of integer objects.

Your interpretation that "an array is an array, period" is acknowledging
only an array in the context of (b) because this context suits your
argument.
If you cannot even acknowledge what an array is how are you ever going to
understand what a pointer to it is.

An array is a contiguous sequence of objects in its most commonly used
context. A single object that points to this sequence is an array-type
object and can ALSO be said to be an array, but you are incorrect to suggest
that this type of object is the only thing that is an array.
 
T

TJorgenson

struct A
{
     int a[25];
};
void foo()
{
     A x = {};
     A y = {};
     x = y; // Does this actually copy an array by value?
}
According to the standard, is the array above, wrapped in a struct,
actually copied by value, or is there another way the C++ standard
describes this behavior? How does member-wise copy apply to array
members?

Nesting an array in a struct is a common C trick used for copying (any
therefore passing by value) arrays.  Why the trick is necessary goes way
back into the history of C.

Yes, I understand that. What I am asking is how the standard addresses
this "loophole". Does the standard describe that array members are
copied? Perhaps the standard specifies that each of the array items is
individually copied?

How is member-wise copy described by the standard with ragard to array
members?
How does the standard describe how member arrays within a struct
passed by value to a function are copied?

Just curious.

Thanks,
Tony
 
P

Peter Remmers

Am 22.04.2011 15:26, schrieb Paul:
Peter Remmers said:
Am 22.04.2011 02:56, schrieb Paul:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that is
the
array.
Regarding the pointer value, it does:
No it doesn't.
Yes it does. If you run the code, you'll see that it prints the same value.
If you access an object in memory by means of dereferencing a pointer, the
accessed object is what the pointer is pointing to.
The "type vs. actual object" debate is still open. But for this thread's
context let's say it does.
When you dereference the pointer 'p' above you access the object in memory
that 'p' points to. Ok.
If you examine this pointed to object you will find it
has a memory address value.
What's a memory address value?
It does have an address. This address is of course the value of the
pointer we dereferenced to reach this object. So far so good.
You have not accessed the array of integers, you
Yes we have. We have reached the actual array elements. If you run my
snippet, you'll see that the pointer's value is the same as the address
of the first element of the array.
have accesssed another pointer-type object.
A big no.

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.
Therefore this pointer can only be said to indirectly point to an array of
integers,
It only indirectly points to the array elements. It directly points to
the array. The indirection, however, is just a compile-time thing,
because it's just a matter of type. As per the pointer value, it
directly points to the actual elements of the array. Dereferencing the
pointer twice does not mean we need to jump around in memory twice.
in the same way a pointer to pointer to int indirectly points to
an int for example:

....unlike a pointer to an actual pointer.
int x;
int* p=&x;
/*This pointer points to an int*/
/*When dereferenced you access the int object*/ Yes.

int** pp =&p;
/* This pointer points to a pointer to int.*/
/*When dereferenced you access another pointer object*/
/*This is an indirect pointer to int because its needs to be dereferenced
twice to access the int object*/
And because it stores another address in memory. Pointer to pointer: two
pointer objects in memory, two memory addresses in memory, two jumps for
two dereferences.
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.
/*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)
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).
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.
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.
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".
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.

.... and by explicitly saying that:
Yes but 'a' is an object that already points to the array.
Yawn.... 'a' *is* the array itself, because it has been declared to *be*
an array, conforming to Section 8.3.4 of the standard.
But when we take the address of 'a'
When you take the address of an array, you get a pointer to an array,
like with any other object there is.
we are creating a pointer to something
that already points to the array.
No. We create a pointer to something that can decay to a pointer to the
first element, but that is not a pointer itself.
This is why we need to dereference such a pointer twice to access the array.
We need to dereference the pointer that an array decays to, in order to
access the array elements.
There is no such thing as an "identifier object".

Peter
 
P

Peter Remmers

Am 22.04.2011 21:15, schrieb Peter Remmers:
Am 22.04.2011 15:26, schrieb Paul:
And with :
int arr[10] ={0};
int (*p)[10] =&arr;
/*dereferencing this accesses an object that holds the address of arr. */

Think about what you have written.

You have taken the address of arr and assigned it to a pointer. Now that
pointer holds the address of arr. Then you say that when you dereference
that pointer, you access an object that holds the address of arr.

What you basically say is that for some pointer foo:

foo == &foo

which can only be true when foo points to itself. But in the above
example, p of course points to arr and not to p.

Peter
 
P

Paul

Peter Remmers said:
Am 22.04.2011 15:26, schrieb Paul:
Applying the& operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.

Sorry for replying to Paul, but I just had to for this brilliant gem.

int x;
int* y =&x;
That is taking the address of an int object, and assigning it to a
pointer object.

int* x;
int** y =&x;
That is taking the address of a pointer object, and assigning it to a
/
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And what do you think happens when you do this:

int arr[10];
int (*p)[10] =&arr;


This pointer does not point to the sequence of integer objects that
is
the
array.
Regarding the pointer value, it does:
No it doesn't.
Yes it does. If you run the code, you'll see that it prints the same
value.
I have run the code and when I dereferenced this pointer, it did not access
the array.
The "type vs. actual object" debate is still open. But for this thread's
context let's say it does.

What's a memory address value?
It does have an address. This address is of course the value of the
pointer we dereferenced to reach this object. So far so good.

Yes we have. We have reached the actual array elements. If you run my
snippet, you'll see that the pointer's value is the same as the address of
the first element of the array.
If you access some object who's value is the address of the array, you are
not accessing the array. TO access the array you must access the data in the
array, not the data in another object.
..
A big no.

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.

Values? Plural values? No when you dereference a pointer there is only one
value, you cannot address arrays of objects.
It only indirectly points to the array elements. It directly points to the
array.
It doesn't it points to an array-type object. When its dereferenced it does
not access the array.
When a pointer points to something , dereferencing it accesses the pointed
to entity, not some other entity..
The indirection, however, is just a compile-time thing, because it's just
a matter of type. As per the pointer value, it directly points to the
actual elements of the array. Dereferencing the pointer twice does not
mean we need to jump around in memory twice.

When you dereference a pointer you access what is pointed to.
Accessing an array-type object, its not the same thing as accessing an array
of objects.
in the same way a pointer to pointer to int indirectly points to
an int for example:

...unlike a pointer to an actual pointer.
int x;
int* p=&x;
/*This pointer points to an int*/
/*When dereferenced you access the int object*/ Yes.

int** pp =&p;
/* This pointer points to a pointer to int.*/
/*When dereferenced you access another pointer object*/
/*This is an indirect pointer to int because its needs to be dereferenced
twice to access the int object*/
And because it stores another address in memory. Pointer to pointer: two
pointer objects in memory, two memory addresses in memory, two jumps for
two dereferences.
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.

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

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.
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.
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?
... and by explicitly saying that:

Yawn.... 'a' *is* the array itself, because it has been declared to *be*
an array, conforming to Section 8.3.4 of the standard.
No 'a' is defined in the standard to be an array-type identifier.
It is not modifiable, if 'a' was the array itself that would suggest that
all arrays are non modifiable.

When you take the address of an array, you get a pointer to an array, like
with any other object there is.
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.
No. We create a pointer to something that can decay to a pointer to the
first element, but that is not a pointer itself.
It is an array-type object, which is a non modifiable object. And its value
is that of a memory address.

We need to dereference the pointer that an array decays to, in order to
access the array elements.

There is no such thing as an "identifier object".
From the standards 8.3.4 Arrays:
"then the type of the identifier of D is an array type."

So the identifier is 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.
 
P

Paul

Peter Remmers said:
Am 22.04.2011 21:15, schrieb Peter Remmers:
Am 22.04.2011 15:26, schrieb Paul:
And with :
int arr[10] ={0};
int (*p)[10] =&arr;
/*dereferencing this accesses an object that holds the address of arr.
*/

Think about what you have written.

You have taken the address of arr and assigned it to a pointer. Now that
pointer holds the address of arr. Then you say that when you dereference
that pointer, you access an object that holds the address of arr.
Yes what I mean by this is because arr is not modifiable when we dereference
it we do not access a modifiable memory location but, when read, it gives us
the address that arr holds.

I admit the original wording there is all wrong.
 
P

Peter Remmers

Am 22.04.2011 22:12, schrieb Paul:
I have run the code
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top