Problem with array objects

[Paul]

You even quoted me saying it.

Altogether now! No I didn't.

(*pparr) and arr have the same type. So whatever applies to one, applies
to the other.

I told you they had the same type , they are array-type objects and they
cannot access the array without being converted to either a pointer or a
reference.
Under no circumstances can dereferencing pparr access the array in the same
way as arr, because pparr needs two derefences and arr only needs one, to
access the array. You cannot dereference arr twice. You MUST derefernece
pparr twice to access the arrray.

Ah, resorting to insults again, good job.

Its not an insult its a fact, and your failure to understand dereferencing
is a clear example.

(*pparr)[0] = 42;

You Fail.
This code dereferences pparr then uses the subscript operator,

Well that is how you access an array! How is it different from
arr[0] = 42?

Your dispute is clear in the the following, which you have tried to avoid by
snipping:

</quote>

If you do not understand that subscripting implicitly converts an array-type
object to a pointer , then please refrain from introducng your confused
stupidity.

 

[Ian Collins]

Altogether now! No I didn't.

Spot the self contradiction:

I told you they had the same type

Under no circumstances can dereferencing pparr access the array in the same
way as arr

So they have the same type but are different. Um, interesting concept.

 

[Ian Collins]

* Ian Collins, on 25.04.2011 01:59:

Please stop.

I had.

 

[Alf P. Steinbach /Usenet]

* Ian Collins, on 25.04.2011 01:59:

On 04/25/11 11:46 AM, Paul wrote:

Spot the self contradiction:

Please stop.


Cheers & tia.,

- Alf

 

[Paul]

I had.

You were proved to be wrong. You had no choice.

 

[Paul]

You are dereferencing an array-type , not an array.
For example:

int arr[40] ={0};
int* parr = arr;
int (*pparr)[40] = &arr;

std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;

Dereferencing pparr does not access the array it accesses a temporary
pointer.
The pointer pparr does not reference the array, it references an
array-type
object.

Dereferencing pparr accesses an array in the same sense that using
the name arr accesses an array.

No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

Derefencing pparr gets you arr. To get what you get by
dereferencing arr, you need to dereference what you get by
dereferencing pparr. The equivalent of

*arr = 1;

is

**pparr = 1;

What happens in both cases is that the array resulting from the
expressions arr and *pparr is treated as a pointer to the first
element of the array. The assginments made to *arr and **pparr
are made to the first elements of the array.

As I said pparr needs to be dereferenced twice to access the array,
derefernecing pparr once doesn't access the array. So it points to an
array-type object , that must be convereted before the array can be
accessed.

[snip]

The (implementation defined) values returned by typeid(a1i).name()
and typeid(*pa1i).name() are the same. The output indicates that
both ai1 and *pai1 are arrays of 4 ints.

No it outputs the type, not the pointed to object.
*pa1i does not derefernece a pointer to the array, it dereferenes a
pointer
to a tempory object of array-type.
Basically its a fancy pointer to a pointer.

I never said that typeid outputs the pointed to object. The
declaration was

int a1i[4], (*pa1i)[4] = &a1i;

pa1i is a pointer to an array. *pa1i dereferences it resulting in
an array. The only objects here are an array (named a1i) and a
pointer to array (named pa1i). There is no pointer to a temporary
object here.

No there are four integer objects here, that you fail to acknowledge.

If you want to count the four subobjects of the array, keep in
mind that they are subobjects of the array rather than objects with
a lifetime independent of the array. The important point is that
there is no pointer to a temporary object here.

[snip]

The following pointer-type
int (*p)[4] =&a1i;
Does not access the array when dereferenced, it accesses an array-type
object. This object is bascially another pointer to the array.
Pointing to an array-type object, is not the same as pointing to the
array
of ints. It points to AN array , yes an array-type object( which is
basically another pointer under the hood), it doesn't point to THE
array
of
ints.

Here, the object named p is a pointer to the array named a1i.
Dereferencing it results that array. The expression

No it doesn't , dererencing this pointer results in a non modifiable
object
that cannot be used to access the array unless converted.
So it results in something that can be converted to a pointer to the
array.

The result of derefencing the pointer is the same as using the name
of the array that the pointer is pointing to. Both of the
expressions (*p) and a1i have the same result. (*p) needs to be
converted to access the array no more than a1i does.

(*p)[int_offset]

access the int_offset element of that array.

[snip]

When you dereference p1i, you create a temporary array-type object the
value
of which is another memory address. You do not get an array of 4 ints,
example:

int arr[4] = {1,2,3,4};
int (*p)[4] = &arr;

std::cout<< *p;

The type of p is an array-type, this means it points to an object of
array-type, not an array of int objects.

There is no temporary array-type object the value of which is
another memory address. There are two objects: an array named arr
and a pointer to array named p. Due to the initialization, p points
the array of int named arr.

Again you fail to acknoweldge the four integer objects.
Where is this object that you describe as "the array named arr" strored?

As I wrote above, if you want to count the four subobjects of the
array, keep in mind that they are subobjects of the array rather
than objects with a lifetime independent of the array. The
important point is that there is no temporary object here.

So where does the memory address value come from? Its not stored in the
array of integer objects.

The array named arr is stored wherever the C++ implementation decides
to store it, as long as the program behaves as specified by the C++
standard. The same is true of the pointer to array named p.

Dereferencing pparr once , yields an object which has a value that is the
address of the array. This object must exist someplace prior to it getting
converted to a pointer.

[snip]

You must be pointing to the array , to point to an element. Where is this
element stored if not witihin the array?

Elements of an array are stored in the region of storage created for
that array. In C++, a pointer to an array and a pointer to an
element of that array are not the same; they have different types.
The assignment

A pointer to an array of integers , is of type int*.
A pointer to an array, in your context, is a pointer to an array-type
object. Which must be dereferenced twice to access the array, the second
dereference will implicitly convert this object to an int*.

*p = 1

is allowed if p is a pointer to an element of an array of int but
not if p is a pointer to an array of int.

A pointer to an array of integers can be 2 different tyes of pointer:
a) A pointer to integers.
b) A pointer to an array-type object.

A pointer to , for example a char array, is generally consider to be of type
char*. An array by nature can only be accesssed one element at a time.

 

[Paul]

You are dereferencing an array-type , not an array.
For example:

int arr[40] ={0};
int* parr = arr;
int (*pparr)[40] = &arr;

std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;

Dereferencing pparr does not access the array it accesses a temporary
pointer.
The pointer pparr does not reference the array, it references an
array-type
object.

Dereferencing pparr accesses an array in the same sense that using
the name arr accesses an array.
No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

Derefencing pparr gets you arr. To get what you get by
dereferencing arr, you need to dereference what you get by
dereferencing pparr. The equivalent of

*arr = 1;

is

**pparr = 1;

What happens in both cases is that the array resulting from the
expressions arr and *pparr is treated as a pointer to the first
element of the array. The assginments made to *arr and **pparr
are made to the first elements of the array.

As I said pparr needs to be dereferenced twice to access the array,
derefernecing pparr once doesn't access the array. So it points to an
array-type object , that must be convereted before the array can be
accessed.

What you wrote was

No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

in reply to "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array."

This statement is incorrect, dereferencing pparr does not access the array
in the same sense as arr.

Your example uses *arr and *pparr as if they were the same; they
are not the same. *arr refers to the first element of the array
while *pparr refers to the array. *pparr and arr both refer to
the array.

So does :
int* p = arr;
So p accesses the array in the same sense as arr.
pparr has another level of indirection.

Because pparr is a pointer to an array, of course it has to be
dereference twice to get the same result as deferencing the array
once. In general, if X points to Y, **X is the same as *Y.

When you have a pointer to an integer you don't derefernece it twice to
access the integer.
So why do you say "of course it has to be dereferneced twice"?
A pointer to something should not have to be dereferenced twice to access
what it points to.

[snip]

When you dereference p1i, you create a temporary array-type object
the
value
of which is another memory address. You do not get an array of 4
ints,
example:

int arr[4] = {1,2,3,4};
int (*p)[4] = &arr;

std::cout<< *p;

The type of p is an array-type, this means it points to an object of
array-type, not an array of int objects.

There is no temporary array-type object the value of which is
another memory address. There are two objects: an array named arr
and a pointer to array named p. Due to the initialization, p points
the array of int named arr.

Again you fail to acknoweldge the four integer objects.
Where is this object that you describe as "the array named arr"
strored?

As I wrote above, if you want to count the four subobjects of the
array, keep in mind that they are subobjects of the array rather
than objects with a lifetime independent of the array. The
important point is that there is no temporary object here.

So where does the memory address value come from? Its not stored in the
array of integer objects.

Where the memory address comes from depends on where the
implementation decides to store the array. For example, an object
with automatic storage duration, such a non-static array declared
in a function, is allocated on the stack in an implementation that
uses a stack for automatic storage.

The compiler knows the compile-time constant offset in the stack
frame where it has decided to store the array. In places where a
program needs the memory address of the array, the compiler puts
in instructions to sum that compile-time constant offset and the
current value of the stack pointer.

This is not a sutable answer , we are talking about array-type object. When
I asked where the memory address was stored I meant in what object, not in
what area of memory.

pparr is a pointer to an array. The address of the array it points
to is stored in the C++ object allocated for pparr.

I'm not sure what you mean by this. The object allocated to ppparr is what
exactly?

Evaluating
*pparr loads that value from memory. In a context where
array-to-pointer conversion is done, there is no additional C++
object whose value is obtained to convert from the address of an
array to a pointer to the first element of the array.

I don't think so , *pparr dereferences a pointer, there is no
array-to-pointer conversion here.

[snip]

A pointer to an array of integers , is of type int*.
A pointer to an array, in your context, is a pointer to an array-type
object. Which must be dereferenced twice to access the array, the second
dereference will implicitly convert this object to an int*.

The type int* is a pointer to int.

Yes the TYPE is "pointer to int". This type of pointer can point to int
object/s(singlular or plural).

A pointer to an array of int is
type int(*)[N], where N is the number of array elements, if known.
A pointer to an array of int is dereferenced once to access the array.

No this is a poointer to array-type objects, not to integer type objects.

It may be dereferenced twice to access the first int in the array.

It MUST be dereferenced twcie, and converted to an int* , to point to any of
the array elements.

Look at the output of the following program.

#include <iostream>
#include <typeinfo>
int main() {
int a1i[4], (*pa1i)[4]=&a1i;

std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;
std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
}

pa1i is a pointer to an array of int; *pa1i an array of int (just
as a1i is); **pa1i is an int.

You are confusing types with what is pointed to.
An array of T , is N x T objects
An array-type object is a different thing altogether.

A pointer to an array of integers can be 2 different tyes of pointer:
a) A pointer to integers.
b) A pointer to an array-type object.

A pointer to an array of integers is a single type of pointer,
int(*)[N], where N is the number of array elements, if known. A
pointer to an integer may point to an element of an array of
integers.

A pointer to , for example a char array, is generally consider to be of
type
char*. An array by nature can only be accesssed one element at a time.

What something is generally considered to be is not necessarily what
it is according to the C++ standard. According to the C++ standard
char(*)[N] is a pointer to an array of char, while char* is a pointer
to a char.

No a char(*)[N] is a TYPE pointer to an array.
Its all about types. An array of objects of type T, is pointed to by a T*.
A T(*)[] type pointer can also point to the array but indirectly.

In some contexts a char* is treated like a pointer to an element of
an array; in some contexts an array is treated like a pointer to its
first element. Because in some contexts a thing is treated as if
it were something else, does not the thing is the something else.

But you have things back to front , a pointer to an array of chars is
firstmost a char*, a char(*)[N] is a pointer to an array-type.

 

[Paul]

news:[email protected]... [snip]
What you wrote was

No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

in reply to "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array."

This statement is incorrect, dereferencing pparr does not access the
array
in the same sense as arr.

In the snipped part, arr and pparr were declared with

int arr[40] = {0};
int (*pparr)[40] = &arr;

An expression that dereferencing pparr has the same result as using
arr; arr and *pparr in expressions have the same type and value. An
example is (*pparr)[3] and arr[3]; they both are the element of arr
3 after its first element.

What is an example where dereferencing pparr does not have the
same result as arr?

You said ..dereferencing pparr accesses the array in the same way as arr,
which it doesn't.
You were/are not accepting the point I was making about dereferncing pparr.
Which was that it does not point to the array directly, it points to an
array-type object.

p does not access an array in the same sense as arr. p and arr are
different types: p is a pointer to int, while arr is an array of int.

It doesn't matter if they are different types, they still access the array
in the same sense, because arr is implicitly converted to the same type as
p.

An array and a pointer are not the same, although in some contexts,
such as that initialization, an array is implcitly converted to a
pointer to it first element.

Nobody is saying an array and a pointer are the same. They access the array
in the same the sense.i.e:
arr[1];
p[1];
Both are subscripted only once to access the array.

pparr is a level of indirection from arr just as any pointer to
something in C++ is a level of indirection from what it points to.

No its not with arrays, an array of integers is pointed to by an int*( in
most cases), it can also be pointed to by an int(*)[N] for the purpose of
converting to reference, for example.

I said pparr is dereferenced twice has the same result as
dereferencing arr (the name of the object that pparr points to).
Dereferencing pparr once has the same result as using arr.

Yes so does this not prove to you that pparr is a different level of
indirection than arr?
pparr is a pointer to an array-type object. This does not automatically
imply that an int* cannot point to an array of integers.

With

int i, *pi = &i;

pi is a level of indirection from i. Dereferencing pi accesses an int
in the same sense that i does. Changing i to declare and array and pi
to declare a pointer to an array, changes the declaration to

int arr[40], (*pparr)[40] = &arr;

Given that declaration, dereferencing pparr accesses an array in the
same sense that arr does, just as prior to the change pi accesses an
int in the same sense that i does.

Yes so this proves that pparr is a different level of indirection than arr.
arr accesses the array by directly converting to a pointer , pparr needs
indirection and then converted to a pointer.

[snip]

This is not a sutable answer , we are talking about array-type object.
When
I asked where the memory address was stored I meant in what object, not
in
what area of memory.

Although it may not be a suitable answer to you, it is what C++
compilers do. You asked "where does the memory address value come
from", and I explained where it comes from.

In C++ an object is a region of storage. The snipped declarations

int arr[4] = {1,2,3,4};
int (*p)[4] = &arr;

allocate an object named arr (and four unmaned subobjects in it) and
an object named p. Because of the initialzation, the expressions **p
and *arr have the same result. The expression **p access only one
stored memory address: the one stored in the object named p. There
is no other object between p and **p.

So answer the question if you are so smart.
What object stores the value of the address we get when we dereference
pparr?

I'm not sure what you mean by this. The object allocated to ppparr is
what
exactly?

The object allocated to pparr is the region of storage used because a
declaration like

int (*pparr)[4];

is in a C++ program.

I don't think so , *pparr dereferences a pointer, there is no
array-to-pointer conversion here.

pparr is a pointer to an array. The result of *pparr is an array.
Array-to-pointer conversion is implicitly done on that result.

That would be pointer-array conversion , not array-pointer.

A pointer to type T may validly point to a single object of type T
(or to the null object) at a given time. In some contexts what it
points to is treated as an element of an array of type T.

A pointer to type T can point to a whole array of T's.
Maybe it cannot access them all at the same time but then , no pointer type
can.

A pointer to an array of int is
type int(*)[N], where N is the number of array elements, if known.
A pointer to an array of int is dereferenced once to access the array.

No this is a poointer to array-type objects, not to integer type objects.

What do you mean "No"? I wrote that it is a "pointer to an array of
int", not a pointer to an int.

But you omit the word TYPE.
A pointer to an array of integer objects, or a single int, is of type int*.
A pointer to an array of int-array-objects, or a single int-array-object ,
is of type int(*)[N]

The result of dereferencing it once is an array, just as the name of
the array in an expression is.

dereferencing it yields an array-type object, you know the one that stores
the memory address, not THE array of integer objects.

In this context, that array is
impliclity converted to a pointer to the first element of the array.
Dereferencing that results in the first element of the array.

Look at the output of the following program.

#include <iostream>
#include <typeinfo>
int main() {
int a1i[4], (*pa1i)[4]=&a1i;

std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;

std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
}

pa1i is a pointer to an array of int; *pa1i an array of int (just
as a1i is); **pa1i is an int.

You are confusing types with what is pointed to.
An array of T , is N x T objects
An array-type object is a different thing altogether.

In C++ an array of type T may be pointed to by a pointer to an array
of type T. An array of type T may also be pointer to by a pointer to
void, but a pointer to void would have be to cast to a pointer to
array to type T before what is pointed to could be used.

In C++ a pointer-type does not define what is pointed to.

A pointer to , for example a char array, is generally consider to be of
type
char*. An array by nature can only be accesssed one element at a time.

What something is generally considered to be is not necessarily what
it is according to the C++ standard. According to the C++ standard
char(*)[N] is a pointer to an array of char, while char* is a pointer
to a char.

No a char(*)[N] is a TYPE pointer to an array.
Its all about types. An array of objects of type T, is pointed to by a
T*.
A T(*)[] type pointer can also point to the array but indirectly.

That's right, it is about types. A T* points to a T, not an array of
T. A (*T)[] points to an array of T. A pointer is a level of
indirection from what it points to. its different with arrays.

In some contexts a char* is treated like a pointer to an element of
an array; in some contexts an array is treated like a pointer to its
first element. Because in some contexts a thing is treated as if
it were something else, does not the thing is the something else.

But you have things back to front , a pointer to an array of chars is
firstmost a char*, a char(*)[N] is a pointer to an array-type.

I have things exactly how they are in the C++ standard, specifically
as in the following example from section 8.1 of the C++ standard.

int // int i
int * // int *pi
int *[3] // int *p[3]
int (*)[3] // int (*p3i)[3]
int *() // int *f()
int (*)(double) // int (*pf)(double)

name respectively the types "int," "pointer to int," "array of 3
pointers to int," "pointer to array of 3 int," "function of (no
parameters) returning pointer to int," and "pointer to a function
of (double) returning int.

According to the C++ standard

int *pi

declares a "pointer to int" and

int (*p3i)[3]

declares a "pointer to array of 3 int". pi may point to an element
in an array of int, but pointing to an element of an array is not
the same as pointing to an array, as p3i does.

No the standard say its of TYPE pointer to array.

 

[Paul]

[snip]
What you wrote was

No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

in reply to "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array."
This statement is incorrect, dereferencing pparr does not access the
array
in the same sense as arr.

In the snipped part, arr and pparr were declared with

int arr[40] = {0};
int (*pparr)[40] = &arr;

An expression that dereferencing pparr has the same result as using
arr; arr and *pparr in expressions have the same type and value. An
example is (*pparr)[3] and arr[3]; they both are the element of arr
3 after its first element.

What is an example where dereferencing pparr does not have the
same result as arr?

You said ..dereferencing pparr accesses the array in the same way as arr,
which it doesn't.

You claim "it doesn't", but you do not provide an example that
supports your claim. I have provided examples that supports mine.

I have provided the proof that pparr needs to be dereferenced twice , and
arr once, to access the array. Thus dereferencing them does not access the
array in the same way.

I know what you mean but what you said is incorrect. You mean that
dereferencing pparr once then makes it the same as arr, so it can then be
subscripted to access the array. But you originally said this in response to
a point I was making about how pparr needs to be dereferenced twice to
access the array. You don't accept the point I was making therefore I do not
accept your statement, which is incorrect anyway.

I don't accept a point about C++ that is not supported by the C++
standard. pparr points directly to the array; it does not point to
another object. Look at the output of the following program.

So what does it access to produce a memory address when dereferenced?

<snip>

 

[Paul]

[snip]
What you wrote was

No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/

in reply to "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array."
This statement is incorrect, dereferencing pparr does not access the
array
in the same sense as arr.

In the snipped part, arr and pparr were declared with

int arr[40] = {0};
int (*pparr)[40] = &arr;

An expression that dereferencing pparr has the same result as using
arr; arr and *pparr in expressions have the same type and value. An
example is (*pparr)[3] and arr[3]; they both are the element of arr
3 after its first element.

What is an example where dereferencing pparr does not have the
same result as arr?
You said ..dereferencing pparr accesses the array in the same way as
arr,
which it doesn't.

You claim "it doesn't", but you do not provide an example that
supports your claim. I have provided examples that supports mine.

I have provided the proof that pparr needs to be dereferenced twice , and
arr once, to access the array. Thus dereferencing them does not access
the
array in the same way.

I wrote: "Dereferencing pparr accesses an array in the same sense
that using the name arr accesses an array." You replied that it
doesn't". Please provide an example that supports your claim that
dereferencing pparr doesn't access an array in the same sense that
using the name arr accesses an array. Dereferencing pparr twice and
arr once does not directly address whether dereferencing pparr (once)
and arr (not at all) access an array in the same sense.

pparr needs to be dereferenced twice , and arr only once, to access the
array.

No, I meant what I wrote: "Dereferencing pparr accesses an array in the
same sense that using the name arr accesses an array." I originally
wrote that in response to what you wrote: "Dereferencing pparr does not
access the array it accesses a temporary pointer." See:
http://groups.google.com/group/comp.lang.c++/msg/d921556db52ce388?hl=en

Let me see if I have this right, you don't accept my statement not
because of what is in the statement but because you, mistakenly,
think the statement was a response to a statemenet about
dereferencing pparr twice.

No your statement is rubbish, because it was in response to the point I said
that pparr needs to be dereferenced twice., which is correct. I was speaking
about dereferencing pparr once and that it does not access the array.
You replied with this nonsense that dereferencing pparr accesses the array
in the same way as arr.

That would be dereferencing pparr twice and dereferencing arr once, which is
not the same at all.

So what does it access to produce a memory address when dereferenced?

I answered that question in lines that you silently snipped from your
followup. Here is the answer again, with 1) the name of the pointer
to array changed to pparr, 2) additional details, and 3) spelling
and grammar corrections.

In C++ an object is a region of storage. The snipped declarations

int arr[4] = {1,2,3,4};
int (*pparr)[4] = &arr;

allocate an object named arr (and four unnamed int subobjects in
it) and an object named pparr. Because of the initialzation, the
expressions **pparr and *arr have the same result. The expression
**pparr accesses only one stored memory address: the one stored in
the object named pparr. There is no other object between pparr
and **pparr that stores a memory address.

No you are wrong. arr stores the address of the array. arr is the array-type
object, that pparr points to.

Evaluating pparr accesses the value stored in the object allocated for
it (the object named pparr).
The value is the memory address of the
array (the value to which pparr was initialized). The result of
evaluating *pparr is the int[4] at that address.

No its the not, it's an object of TYPE int[4]. Evaluating *pparr does not
yield or access 4 integers, it yields an array-type object which has a
memory address value.

The result of
evaluating **pparr is the int at that address, to get this result
there was an implicit array-to-pointer conversion on the array
result of *pparr.

You still do not accept what the result of *pparr is. Evaluating **pparr is
not the question here, I have told you umpteen times that dereferencing
twice accesses the array.

The bottom line is that the expression **pparr accesses only one
stored memory address: the one stored in the object named pparr.

You cannot access a whole array simultaneously. You can only represent this
concept with an object type.

But you fail to answer the question which was what is accessed, with *pparr,
to produce a memory address? You can waffle on all day about what **pparr
accesses but this does not answer the above.
As I have said its an array-type object which stores the address of the
array, you seem to disagree but you are providing no reasonable reasons why.

 

[Ian Collins]

pparr needs to be dereferenced twice , and arr only once, to access the
array.

Would you care to explain the difference between

"Dereferencing pparr accesses an array in the same sense that using the
name arr accesses an array."

and

"pparr needs to be dereferenced twice, and arr only once, to access the
array."?

The former is analogous to

"subtracting 1 from 2 is equivalent to 1"

and latter is analogous to

"subtracting 2 from 2 equivalent to subtracting 1 from 1"

Both are correct.

 

[Paul]

Would you care to explain the difference between

"Dereferencing pparr accesses an array in the same sense that using the
name arr accesses an array."

and

"pparr needs to be dereferenced twice, and arr only once, to access the
array."?

pparr points to an array-type object.
arr points to an array of integer-type objects.

That's the difference.

 

[Paul]

[snip]

pparr needs to be dereferenced twice , and arr only once, to access the
array.

That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array.

Yes it does.

<snip>

 

[Paul]

[snip]
I wrote: "Dereferencing pparr accesses an array in the same sense
that using the name arr accesses an array." You replied that it
doesn't". Please provide an example that supports your claim that
dereferencing pparr doesn't access an array in the same sense that
using the name arr accesses an array. Dereferencing pparr twice and
arr once does not directly address whether dereferencing pparr (once)
and arr (not at all) access an array in the same sense.

pparr needs to be dereferenced twice , and arr only once, to access the
array.

That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array.

Yes it does.

<snip>

You snipped what I wrote after that sentence. What I wrote was

Yes I did because it was complete nonsense.

arr accesses the array by dereferencing only once. pparr accesses the array
by dereferencing twice. Dereferencing pparr does not access the array in the
same way as arr at all, you are speaking complete nonsense.

It doesn't matter how much code or nonsense you post, it won't change the
fact that both have different levels of indirection.

 

[Joshua Maurice]

On May 10, 10:31 am, "A. Bolmarcich" <[email protected]>
wrote:
[snip]

This is for your benefit A. Bolmarcich. I don't think you'll get
anywhere, but to lessen your pain and suffering, let me take a stab at
where Paul is coming from so that you might understand.

For nearly all of the programming world, we recognize a few thinks
that Paul does not. Note that these are almost purely definitional,
which means that you cannot "prove" Paul wrong with evidence or a
scientific argument. Instead, Paul is wrong by definition. Arguments
over definition tend to devolve down into usually not interesting or
convincing arguments IMHO. Either it's clear cut enough that the
correct answer is obvious, such as in this case, or it's ambiguous
enough that you're better off just getting a temporary consensus on
usable terms for the duration of the conversation.

Lots of the recent inane arguments have been because you both have
been arguing with your own particular definitions of the words which
are not shared by your opponent. Thus, the conversation is as if one
is yelling in French and the other in traditional Chinese. It won't
get very far unless and until you agree upon some definitions for the
terms involved, and any future discussion should be framed in that
regard.

1- An array is an object. The elements of an array are sub-objects of
the array. "new int[2]" creates 1 array object, which has 2 sub-
objects of type int. Thus 3 objects in total. Paul will dispute this.
GL there. If I were to try arguing with him, I would start here.

2- A. Bolmarcich wants to narrowly define "accessing the array" as an
expression of array type which refers to the array, or some such. Paul
wants to narrowly define "accessing the array" as an expression of the
element type of the array which refers to an element of the array, or
some such. IMHO, I think both are accepted usage of language, that is
I don't think there's such a clear cut definition of "access" in
usage, so GL to both of you.

3- Paul is making some sort of distinction between "an array object"
and "an array-type object". At least, I think he is, or something.
It's really quite hard to follow because he has never defined those
terms, and because he's wrong insofaras that's how /anyone/ else uses
those words. I've been trying to figure out exactly what he means, but
it's difficult to pierce his terminology.

 

[Ian Collins]

On May 10, 10:31 am, "A. Bolmarcich"<[email protected]>
wrote:
[snip]

This is for your benefit A. Bolmarcich. I don't think you'll get
anywhere, but to lessen your pain and suffering, let me take a stab at
where Paul is coming from so that you might understand.

For nearly all of the programming world, we recognize a few thinks
that Paul does not. Note that these are almost purely definitional,
which means that you cannot "prove" Paul wrong with evidence or a
scientific argument. Instead, Paul is wrong by definition. Arguments
over definition tend to devolve down into usually not interesting or
convincing arguments IMHO. Either it's clear cut enough that the
correct answer is obvious, such as in this case, or it's ambiguous
enough that you're better off just getting a temporary consensus on
usable terms for the duration of the conversation.

The part of his argument that baffles me is he accepts that given

int arr[40] = {0};
int (*pparr)[40] = &arr;

typeid(arr) == typeid(*pparr)

but refuses to accept they access the array in the same way.

Well odd.

 

[Paul]

On May 10, 10:31 am, "A. Bolmarcich"<[email protected]>
wrote:
[snip]

This is for your benefit A. Bolmarcich. I don't think you'll get
anywhere, but to lessen your pain and suffering, let me take a stab at
where Paul is coming from so that you might understand.

For nearly all of the programming world, we recognize a few thinks
that Paul does not. Note that these are almost purely definitional,
which means that you cannot "prove" Paul wrong with evidence or a
scientific argument. Instead, Paul is wrong by definition. Arguments
over definition tend to devolve down into usually not interesting or
convincing arguments IMHO. Either it's clear cut enough that the
correct answer is obvious, such as in this case, or it's ambiguous
enough that you're better off just getting a temporary consensus on
usable terms for the duration of the conversation.

The part of his argument that baffles me is he accepts that given

int arr[40] = {0};
int (*pparr)[40] = &arr;

typeid(arr) == typeid(*pparr)

but refuses to accept they access the array in the same way.

That doesn't even access the array. Confused? obviously you are.

**pparr ; //accesses the array
*arr; //accesses the array

They are not dereferenced to access the array in the same way, one is
dereferenced twice, the other dereferenced once.

*pparr; //Does not access the array.
**arr; //Does not access the array..

 

[Joshua Maurice]

On May 10, 10:31 am, "A. Bolmarcich"<[email protected]>
wrote:
[snip]

This is for your benefit A. Bolmarcich. I don't think you'll get
anywhere, but to lessen your pain and suffering, let me take a stab at
where Paul is coming from so that you might understand.

For nearly all of the programming world, we recognize a few thinks
that Paul does not. Note that these are almost purely definitional,
which means that you cannot "prove" Paul wrong with evidence or a
scientific argument. Instead, Paul is wrong by definition. Arguments
over definition tend to devolve down into usually not interesting or
convincing arguments IMHO. Either it's clear cut enough that the
correct answer is obvious, such as in this case, or it's ambiguous
enough that you're better off just getting a temporary consensus on
usable terms for the duration of the conversation.

The part of his argument that baffles me is he accepts that given

int arr[40] = {0};
int (*pparr)[40] = &arr;

typeid(arr) == typeid(*pparr)

but refuses to accept they access the array in the same way.

Well odd.

As I said specifically in my post which you snipped, I was very clear
on what I think his interpretation is. It answers your question. He
thinks that the expression " arr " does not access the array, and "
*pparr " does not access the array. Quote "It only accesses the array-
type object" or some such insanity. Only " *arr " and " **pparr "
access the array. He claims that an array access is the same thing as
an access of an array element, whereas you say an expression of array
type that refers to the array accesses the array. He makes this very
clear in the post replying to you, and it's been clear else-where as
well.

As for what I think? I don't know of a clear cut definition of
"access". I'd much prefer "access" to mean a read or a write from a
personal preference. With that definition in mind, you usually
(never?) read or write an array object as a whole, and you only read
or write in terms of its elements. Still, I recognize that the word
"access" means a lot of things to a lot of different people, and there
is no standardized definition in this context AFAIK, so I don't make a
big fuss out of it. I would make a big fuss if someone started talking
sloppily or ambiguously about reads and writes of array objects,
because that has thread considerations, specifically race conditions.
In that context, precision and accuracy are important.

Consider:

int arr[10];

arr;
//Accesses the array in some fluffy sense yes.
//Can this participate in a race condition? I /think/ no.

arr[0];
//Accesses an array element in some fluffy sense yes.
//Can this participate in a race condition? I /think/ no.

int x = arr[0];
//Is a read of an array element.
//Can participate in a race condition.

A read requires more than just an expression of that type IIRC.

 

[Paul]

This is for your benefit A. Bolmarcich. I don't think you'll get
anywhere, but to lessen your pain and suffering, let me take a stab at
where Paul is coming from so that you might understand.

For nearly all of the programming world, we recognize a few thinks
that Paul does not. Note that these are almost purely definitional,
which means that you cannot "prove" Paul wrong with evidence or a
scientific argument. Instead, Paul is wrong by definition. Arguments
over definition tend to devolve down into usually not interesting or
convincing arguments IMHO. Either it's clear cut enough that the
correct answer is obvious, such as in this case, or it's ambiguous
enough that you're better off just getting a temporary consensus on
usable terms for the duration of the conversation.

The part of his argument that baffles me is he accepts that given

int arr[40] = {0};
int (*pparr)[40] = &arr;

typeid(arr) == typeid(*pparr)

but refuses to accept they access the array in the same way.

Well odd.

As I said specifically in my post which you snipped, I was very clear
on what I think his interpretation is. It answers your question. He
thinks that the expression " arr " does not access the array, and "
*pparr " does not access the array. Quote "It only accesses the array-
type object" or some such insanity.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*pparr access an array-type object , which decays to a pointer at the
slightest useage.
*pparr does not access the array.
<snip>

 

[Paul]

[snip]
I wrote: "Dereferencing pparr accesses an array in the same sense
that using the name arr accesses an array." You replied that it
doesn't". Please provide an example that supports your claim that
dereferencing pparr doesn't access an array in the same sense that
using the name arr accesses an array. Dereferencing pparr twice and
arr once does not directly address whether dereferencing pparr
(once)
and arr (not at all) access an array in the same sense.

pparr needs to be dereferenced twice , and arr only once, to access
the
array.

That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array.

Yes it does.

<snip>

You snipped what I wrote after that sentence. What I wrote was

Yes I did because it was complete nonsense.

It wasn't nonsense; it was evidence that supported my statement.
By snipping it you gave the misimpression that I made the statement
without giving supporting evidence. Now, you snipped it again.

What is accessed when you dereference pparr once?

Are you incapable of using a compiler to find this out?

You speak utter nonsense, and I am considering ignoring further posts from
you because of your unreasonableness.

The fact that dereferencing pparr twice and arr once both result in
the first element of the array is consistent

Its consistent with **** all you arsehole.
THere is **** all that is consistent about dereferencing pparr twice and arr
once, except that it proves they are different levels of indirection. WHich
is what I have been telling you all along.


Dereferencing pparr once accesses what?

You dont seem to know.

The array accessed by dereferencing pparr once and arr not at all
is implicitly converted to a pointer to the first element of the
array. Dereferencing that pointer accesses the first element of
the array.

NO ARRAY IS ACCESED WHEN DEREFERENCING PPARR ONCE !

Are you stupid as well as incapable of using a compiler.

If you think I am wasting my time arguing with an idiot like you you can go
**** yourself. Accept the facts arsehole, I've had enough of your
unreasonable idiocy.