Problem with array objects

[Thomas David Rivers]

To return to that, do you agree that in this declaration:

int arr[5];

'arr' is the name of the contigous set of 5 `int' elements?

And, to go to the next step, would you agree that in this
declaration:

int i;

`i' is the name of single `int'?

Yes I agree, you may continue.





So - we should then consider something fairly important... what does
"name" mean?

I would ask that we consider the 'name' of something to be the
designation of the location that contains that 'something'. And, I
want
to movitave that definition with the following scenario.

If we can imagine that variables, in the C/C++ sense, are simply
"boxes" that contain their values - like shoeboxes on a shelf,
then the "name" associated with the variable is simply the name
associated with a "box." Let's imagine that this shelf can contain
many boxes, and that the boxes are numbered... box #0, box #1, box
#2..

A box can be referred to by its number - its location on the shelf,
or if
we associate a name with a box #; we can use the name. For example,
box #51 might have the name `i' associated with it.

Thus, if we consider this snippet of C code:


int i;
i = 5;

the semantics of that would be something similar to:

define a box name 'i', allocate space for it, let's say that is
box #51, associate
location #51 with the name 'i'.

produce the manifest `int' constant 5
Find the box with the name 'i', oh - it's box #51.
store the manifest constant 5 into box #51.



Similarly, the snippet:

int i,j;
i = j;

might be realized in this way:

define a box named 'i' that can contain int-typed objects, say,
box #51.
define a box named 'j' that can contain int-typed objects, say,
box #52.

Given the name 'j'; find its box - oh - it's box #52.
Retrieve (fetch) the value from box #52.
Given the name 'i'; find its box - oh - it's box #51.
Store the value previously fetched value into box #51.


So far, I've only talked about boxes that can contain `int'-typed
values.

Let's introduce a new box, and say that it can contain the location
(the box #)
of another box, and the other box can contain `int'-typed values.
We would
call this new box a "pointer" to an `int'-typed box, because it
doesn't contain
the `int'-type value itself, but instead tells us the location (the
box #) of the
value.

Now - let's consider this:

int *ip;
int i;

ip = &i;

in this mindset - what does this mean? To discuss this, we need to
define
the &-operator. Le's say that the &-operator is named 'address of'
and that
it returns the location (the box #) of its operand. Say, for
example, if `i'
happened to be box #51, then the expression "&i" would produce
location #51.

Remember - I can have two kinds of boxes on my shelf, boxes that
contain
`int'-typed values, and boxes that contain the location of other
`int'-typed boxes.
So, &i doesn't produce an `int'-typed value, it produces a
location. In this
example, it produced #51. (I have been careful to use '#' to
indicate location numbers
instead of simple `int'-typed values.. this distinction will become
important.)

So - the semantics of that statement would be (if I may be so bold
as to be a little loose on the details):

define a box named 'ip' - it can contain the location of other
`int'-typed boxes,
let's say it is box #52.
define a box named 'i' - it can contain `int' values, let's say
it's box #51.

Apply the &-operator to the box named `i' - oh - i is box #51, so
&i produces
the location #51.
Look up the name `ip - oh - that's box #52.
Store our previously found location (#51) into box #52.


OK - now - let's say that I happen to buy my boxes from a
manufacturer that
can only make 2-kinds of boxes, those boxes that can contain `int'
elements,
and those boxes that can contain the location of other boxes that
contain
`int' elements. (that is, `int' boxes and `int *' boxes).
So, let's look at this:

int *ip;
int arr[5];


What can this do? I propose it does the following:

define a box named 'ip', that box is allowed to contain the
location of
other `int'-type boxes; let's say that is box #52.
define a space of 5 boxes, each of these boxes is on the shelf
starting
at, say, location #53. Each of these boxes is an `int'-typed
box. The
boxes are contiguous, starting a location #53 and going thru
location
#57 (inclusive.) Since `arr' (at the C/C++ level) is a
single object,
the location associated with `arr' is #53 (the start of the 5
contiguous
boxes on the shelf.)

That is, in this scenario, the location of 'ip' is box #52, the
location of 'arr'
is box #53. `ip' uses one box, `arr' uses 5 boxes.

With this, we can provide a definition of "name".... the "name" of
the variable
provides a mechanism for finding precisely which "box" (the box #,
or location
of the box) houses the value of the variable. The "name" is
nothing more than
a convenience for mapping the location of the variable.
So - in our example, the name 'ip' is asociated with box #52, the
name 'arr'
is associated with box #53.

Before I go on, I want to check to see if you agree with everything
so far...

I agree with you that the "name" provides a mechanisn for mapping
the location but....
The names 'i', 'ip' and 'arr' have different name mechanisms.
The name 'i' refers to box#51, when used in an expression it
evaluates to whatever is contained in box#51.
The name 'ip' refers to box#52, it evaluates to whatever is
contained in box#52.

The name 'arr' refers to box#53.... but it does not evaluate to the
contents of box#53. It evaluates to the address of box#53.

I left all of the context above, so we have something to refer to....

And - yes - you are absolutely right... the name 'arr' refers to
the start of
the array... that is; as you correctly point out above; 'arr' would
refer to box #53.
To echo your statement, the name 'arr' does not refer to the contents of
boxes #53 thru #57 - it, in many contexts, refers to the location #53.
Similarly, the name 'ip' denotes box #52... but, as you correctly
point out,
the context in which the name is referenced is key to understanding
what is
happening.

For example, in this snippet:

int i, j;
i = j;

On the right-hand-side of the assignment operator, we find 'j' - that
refers
to the contents of the box at the location associated with the name
'j'. In C, we call
that an "rvalue". On the left-hand-side, we find 'i'. That refers
to the location of 'i',
the location used for storing the value computed on the
right-hand-side. In C, we call than an "lvalue". Note that, in both
instances, the names do refer to the location
of the boxes - it is simply what is done with that location that
changes. In the rvalue
context, we fetch the contents of the box, on the lvalue side, we
store the value into
the box.

(Note that 'j' in the assignment expression is first an "lvalue" and
is converted
into an "rvalue" by the rules of the language. It is this treatment
that indicates
that the value is to be retrieved from the box.)

As you mentioned above, the context is critical to understanding what
is going
on. I commend you on recognizing that distinction.

Thus - we now need to consider what it means in C/C++ when we encounter
an expression using the name of an array.

The way this is encapsulated in the C/C++ language is the rule regarding
conversion of an lvalue with an array type to a pointer to the first
element
of the array.

So - if we now consider this:

int *ip;
int arr[5];

ip = arr;

What would happen in our "shoebox" world? If we use your absolutely
correct
observation, then it would be this:

define a box named "ip", say - box #52 - that box can contain the
location of
other `int'-typed boxes
define a space of 5 boxes, beginning at box #53 thru box #57;
name that
area 'arr' by associating 'arr' with box #53

Now - how do we evaluate the expression "arr" in the context of the
assignment statement? Well, according to the C language rules, when
you discover an lvalue that has a type 'array'; you convert that into
the address of its first element.

Thus, we can say that:

ip = arr;

can be evaluated as:

Look up the name 'arr' - oh, it is an array of 5 `int'-typed
boxes. According
to the rules, in this context, we should produce the location
of the
first box of the array, that would be location #53.
Look up the name 'ip' - oh - that is a box (at location #52) that
can contain the location
of other `int'-typed boxes.
Store the value previously found location (#53) into box #52.

As you had correctly forseen, we are able to evaluate this using the
rules
of the programming language.

Note that, there wasn't a "extra" shoebox allocated/needed to produce
the result.

Note that the 'name' did not mean some other space was allocated...
it simply
refers to the location, as we have previously shown/agreed to.

This behaviour is different to other C++ names.
For example given the name of an int or an int*:

int x=7;
int* p =7;

When we use the names of a object in C++ we expect the the object to
be addressed and the value accessed whether it be a read or write
operation.
With an arr the situation is different , when we use the name of an
array we do not expect the array to be addressed , instead we expect a
pointer to the array:
int* = arr;

The identifier or name 'arr' refers to an array of objects yet somehow
its value is an address , not the same value as any of the objects it
refers to.


In C++

You are correct.. the reason for your correctness has been detailed
above.

For arrays, there is a "special" rule.. this rule is only for arrays,
the rule
is that when the array name is used, it does not designate the entire
array, it designates the address of the first element.

I am glad that you have reached this understanding, and that you have
expressed your agreement!

That is, when you reference an array name, it does not denote the entire
array; nor is there any other special object that is created to point to the
array - it is simply that the result of the reference is the address of the
first element (which you pointed out above.)

Now - given that understanding, I suggest that given this
declaration:

int arr[5];

that the expression

(&arr[0])

is also the address of the first element of 'arr' - do you not agree?


- Dave Rivers -

 

[Joshua Maurice]

Consider the code:

     int arr[5]={0};
     std::cout << "&arr[0] = " << &arr[0] << std::endl;
     std::cout << "&arr = " << &arr << std::endl;

By language rules the address of first element of array and address of
array itself are same.

Citation please? I am unaware of any rule that guarantees the
following:

#include <cassert>
int main()
{
int x[3];
int (*y)[3] = &x;
void* px = x;
void* py = y;
assert(px == py);
}

I think that this would be true on most desktops, but I am unsure if
this is guaranteed. I would guess that it is not.

 

[Paul]

Paul wrote:




To return to that, do you agree that in this declaration:

int arr[5];

'arr' is the name of the contigous set of 5 `int' elements?

And, to go to the next step, would you agree that in this
declaration:

int i;

`i' is the name of single `int'?

Yes I agree, you may continue.





So - we should then consider something fairly important... what does
"name" mean?

I would ask that we consider the 'name' of something to be the
designation of the location that contains that 'something'. And, I
want
to movitave that definition with the following scenario.

If we can imagine that variables, in the C/C++ sense, are simply
"boxes" that contain their values - like shoeboxes on a shelf,
then the "name" associated with the variable is simply the name
associated with a "box." Let's imagine that this shelf can contain
many boxes, and that the boxes are numbered... box #0, box #1, box
#2..

A box can be referred to by its number - its location on the shelf, or
if
we associate a name with a box #; we can use the name. For example,
box #51 might have the name `i' associated with it.

Thus, if we consider this snippet of C code:


int i;
i = 5;

the semantics of that would be something similar to:

define a box name 'i', allocate space for it, let's say that is box
#51, associate
location #51 with the name 'i'.

produce the manifest `int' constant 5
Find the box with the name 'i', oh - it's box #51.
store the manifest constant 5 into box #51.



Similarly, the snippet:

int i,j;
i = j;

might be realized in this way:

define a box named 'i' that can contain int-typed objects, say, box
#51.
define a box named 'j' that can contain int-typed objects, say, box
#52.

Given the name 'j'; find its box - oh - it's box #52.
Retrieve (fetch) the value from box #52.
Given the name 'i'; find its box - oh - it's box #51.
Store the value previously fetched value into box #51.


So far, I've only talked about boxes that can contain `int'-typed
values.

Let's introduce a new box, and say that it can contain the location
(the box #)
of another box, and the other box can contain `int'-typed values. We
would
call this new box a "pointer" to an `int'-typed box, because it
doesn't contain
the `int'-type value itself, but instead tells us the location (the
box #) of the
value.

Now - let's consider this:

int *ip;
int i;

ip = &i;

in this mindset - what does this mean? To discuss this, we need to
define
the &-operator. Le's say that the &-operator is named 'address of'
and that
it returns the location (the box #) of its operand. Say, for
example, if `i'
happened to be box #51, then the expression "&i" would produce
location #51.

Remember - I can have two kinds of boxes on my shelf, boxes that
contain
`int'-typed values, and boxes that contain the location of other
`int'-typed boxes.
So, &i doesn't produce an `int'-typed value, it produces a location.
In this
example, it produced #51. (I have been careful to use '#' to
indicate location numbers
instead of simple `int'-typed values.. this distinction will become
important.)

So - the semantics of that statement would be (if I may be so bold
as to be a little loose on the details):

define a box named 'ip' - it can contain the location of other
`int'-typed boxes,
let's say it is box #52.
define a box named 'i' - it can contain `int' values, let's say it's
box #51.

Apply the &-operator to the box named `i' - oh - i is box #51, so &i
produces
the location #51.
Look up the name `ip - oh - that's box #52.
Store our previously found location (#51) into box #52.


OK - now - let's say that I happen to buy my boxes from a manufacturer
that
can only make 2-kinds of boxes, those boxes that can contain `int'
elements,
and those boxes that can contain the location of other boxes that
contain
`int' elements. (that is, `int' boxes and `int *' boxes).
So, let's look at this:

int *ip;
int arr[5];


What can this do? I propose it does the following:

define a box named 'ip', that box is allowed to contain the
location of
other `int'-type boxes; let's say that is box #52.
define a space of 5 boxes, each of these boxes is on the shelf
starting
at, say, location #53. Each of these boxes is an `int'-typed
box. The
boxes are contiguous, starting a location #53 and going thru
location
#57 (inclusive.) Since `arr' (at the C/C++ level) is a single
object,
the location associated with `arr' is #53 (the start of the 5
contiguous
boxes on the shelf.)

That is, in this scenario, the location of 'ip' is box #52, the
location of 'arr'
is box #53. `ip' uses one box, `arr' uses 5 boxes.

With this, we can provide a definition of "name".... the "name" of the
variable
provides a mechanism for finding precisely which "box" (the box #, or
location
of the box) houses the value of the variable. The "name" is nothing
more than
a convenience for mapping the location of the variable.
So - in our example, the name 'ip' is asociated with box #52, the name
'arr'
is associated with box #53.

Before I go on, I want to check to see if you agree with everything so
far...

I agree with you that the "name" provides a mechanisn for mapping the
location but....
The names 'i', 'ip' and 'arr' have different name mechanisms.
The name 'i' refers to box#51, when used in an expression it evaluates
to whatever is contained in box#51.
The name 'ip' refers to box#52, it evaluates to whatever is contained
in box#52.

The name 'arr' refers to box#53.... but it does not evaluate to the
contents of box#53. It evaluates to the address of box#53.


I left all of the context above, so we have something to refer to....

And - yes - you are absolutely right... the name 'arr' refers to the
start of
the array... that is; as you correctly point out above; 'arr' would
refer to box #53.
To echo your statement, the name 'arr' does not refer to the contents of
boxes #53 thru #57 - it, in many contexts, refers to the location #53.
Similarly, the name 'ip' denotes box #52... but, as you correctly point
out,
the context in which the name is referenced is key to understanding what
is
happening.

For example, in this snippet:

int i, j;
i = j;

On the right-hand-side of the assignment operator, we find 'j' - that
refers
to the contents of the box at the location associated with the name 'j'.
In C, we call
that an "rvalue". On the left-hand-side, we find 'i'. That refers to
the location of 'i',
the location used for storing the value computed on the right-hand-side.
In C, we call than an "lvalue". Note that, in both instances, the
names do refer to the location
of the boxes - it is simply what is done with that location that
changes. In the rvalue
context, we fetch the contents of the box, on the lvalue side, we store
the value into
the box.

(Note that 'j' in the assignment expression is first an "lvalue" and is
converted
into an "rvalue" by the rules of the language. It is this treatment
that indicates
that the value is to be retrieved from the box.)

As you mentioned above, the context is critical to understanding what is
going
on. I commend you on recognizing that distinction.

Thus - we now need to consider what it means in C/C++ when we encounter
an expression using the name of an array.

The way this is encapsulated in the C/C++ language is the rule regarding
conversion of an lvalue with an array type to a pointer to the first
element
of the array.

So - if we now consider this:

int *ip;
int arr[5];

ip = arr;

What would happen in our "shoebox" world? If we use your absolutely
correct
observation, then it would be this:

define a box named "ip", say - box #52 - that box can contain the
location of
other `int'-typed boxes
define a space of 5 boxes, beginning at box #53 thru box #57; name
that
area 'arr' by associating 'arr' with box #53

Now - how do we evaluate the expression "arr" in the context of the
assignment statement? Well, according to the C language rules, when
you discover an lvalue that has a type 'array'; you convert that into
the address of its first element.

Thus, we can say that:

ip = arr;

can be evaluated as:

Look up the name 'arr' - oh, it is an array of 5 `int'-typed boxes.
According
to the rules, in this context, we should produce the location of
the
first box of the array, that would be location #53.
Look up the name 'ip' - oh - that is a box (at location #52) that
can contain the location
of other `int'-typed boxes.
Store the value previously found location (#53) into box #52.

As you had correctly forseen, we are able to evaluate this using the
rules
of the programming language.

Note that, there wasn't a "extra" shoebox allocated/needed to produce
the result.

Note that the 'name' did not mean some other space was allocated... it
simply
refers to the location, as we have previously shown/agreed to.

This behaviour is different to other C++ names.
For example given the name of an int or an int*:

int x=7;
int* p =7;

When we use the names of a object in C++ we expect the the object to be
addressed and the value accessed whether it be a read or write operation.
With an arr the situation is different , when we use the name of an array
we do not expect the array to be addressed , instead we expect a pointer
to the array:
int* = arr;

The identifier or name 'arr' refers to an array of objects yet somehow
its value is an address , not the same value as any of the objects it
refers to.


In C++

You are correct.. the reason for your correctness has been detailed
above.

For arrays, there is a "special" rule.. this rule is only for arrays, the
rule
is that when the array name is used, it does not designate the entire
array, it designates the address of the first element.

I am glad that you have reached this understanding, and that you have
expressed your agreement!

That is, when you reference an array name, it does not denote the entire
array; nor is there any other special object that is created to point to
the
array - it is simply that the result of the reference is the address of
the
first element (which you pointed out above.)

Now - given that understanding, I suggest that given this
declaration:

int arr[5];

that the expression

(&arr[0])

is also the address of the first element of 'arr' - do you not agree?

Yes I agree.

 

[Paul]

On 29/05/2011 20:43, Paul wrote:

[snip]

A pointer to an array of integer objects is of type int*.

Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]

No I am not wrong, int* can point to a single int or an array of integers as
shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with the
subscripting syntax T[N], where N is the, zero based, Nth element of the
array.

 

[Paul]

On 29/05/2011 20:43, Paul wrote:

[snip]

A pointer to an array of integer objects is of type int*.

Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]

No I am not wrong, int* can point to a single int or an array of integers
as shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with the
subscripting syntax T[N], where N is the, zero based, Nth element of the
array.

In C++ a pointer to a single value of type T can be used to access the
value with the subscripting syntax ip[0]. A pointer to int points to (wait
for it...) an int.

In the expression :
int* p_arr= new int[66];
the pointer points to an array of integers, not a single integer.

Yes you could say that the pointer only points to one single integer, but it
also points to the array of integers.
To suggest that it points to one single integer and only one single integer
is incorrect, narrow minded and ignorant of the fact that it actually points
to an array of integers.

 

[SG]

Paul said:

[...]

In C++ a pointer to a single value of type T

Keep in mind that "pointer to a single..." has a special meaning for
Paul. While for you (and everybody else except Paul) "single" here
means the type of the pointer is T*
as opposed to T(*)[N] for N>1. For Paul the pointer type is always T*
and "pointer to a single..." describes some runtime state, that is,
the pointer's value is currently the address of a single object that
is NOT part of a multi-element array.

can be used to access the
value with the subscripting syntax ip[0].

Sure. But given Paul's understanding of "pointer to single..." any
index other than zero would be illegal. For indices other than zero
the pointer would have to be a "pointer to an array" (to use this
words ... which can be translated to "pointer to an element of an
array" in proper-speak).

A pointer to int points to (wait for it...) an int.

Sure it does. What people need to realize is that Paul is stuck in a
certain mindset. In this mindset "pointing to..." and a pointer
expression's type don't correlate much. This becomes obvious with his
broken finger/banana/bunch-of-bananas analogy (broken because a finger
has no type w.r.t. what it can point to). Especially the "an array is
just a pointer [with additional magical type info w.r.t. array size]"-
way-of-thinking is what makes his mental model of arrays and pointers
more complicated than it has to be. Different mental model. Different
terminology. And any attempt to make him understand this proved to be
futile. I'm actually surprized that people still respond to him. It's
all been said before.

So, if anyone feels like responding to him, please check what kind of
responses he got in the past, how he reacted to them and reevaluate
whether a response would be time well-spent.

Cheers!
SG

 

[Michael Doubez]

On 29/05/2011 20:43, Paul wrote:
[snip]
A pointer to an array of integer objects is of type int*.
Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.
[snip]

No I am not wrong, int* can point to a single int or an array of
integers as shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with
the subscripting syntax T[N], where N is the, zero based,  Nth element
of the array.

In C++ a pointer to a single value of type T can be used to access the
value with the subscripting syntax ip[0]. A pointer to int points to
(wait for it...) an int.

Well, to be totally fair, there is one occurrence where this is not
true:

int* p = new int[0];

p points to an array with no elements and p doesn't point to an int.

 

[Paul]

Paul said:

[...]

In C++ a pointer to a single value of type T

Keep in mind that "pointer to a single..." has a special meaning for
Paul. While for you (and everybody else except Paul) "single" here
means the type of the pointer is T*
as opposed to T(*)[N] for N>1. For Paul the pointer type is always T*
and "pointer to a single..." describes some runtime state, that is,
the pointer's value is currently the address of a single object that
is NOT part of a multi-element array.

can be used to access the
value with the subscripting syntax ip[0].

Sure. But given Paul's understanding of "pointer to single..." any
index other than zero would be illegal. For indices other than zero
the pointer would have to be a "pointer to an array" (to use this
words ... which can be translated to "pointer to an element of an
array" in proper-speak).

A pointer to int points to (wait for it...) an int.

Sure it does. What people need to realize is that Paul is stuck in a
certain mindset. In this mindset "pointing to..." and a pointer
expression's type don't correlate much. This becomes obvious with his
broken finger/banana/bunch-of-bananas analogy (broken because a finger
has no type w.r.t. what it can point to). Especially the "an array is
just a pointer [with additional magical type info w.r.t. array size]"-
way-of-thinking is what makes his mental model of arrays and pointers
more complicated than it has to be. Different mental model. Different
terminology. And any attempt to make him understand this proved to be
futile. I'm actually surprized that people still respond to him. It's
all been said before.

There is nothing broken about the banana analogy.

Another example is a box of strawberries, if you point to a strawberry in a
box , you canot do so without also pointing at the box of strawberries. To
say you are pointing at strawberry#51, for example, is simply being specific
about which strawberry you are pointing too, you are also pointing at the
box of strawberries when you point to strawberry51.

std::string strawberries[120];
strawberries[51] = "tasty";

std::string* p_strawberries = strawberries;
std::string strawberry = strawberries[51];

 

[Fred Zwarts \(KVI\)]

"Paul" wrote in message news:[email protected]...

Paul said:
[...]

In C++ a pointer to a single value of type T

Keep in mind that "pointer to a single..." has a special meaning for
Paul. While for you (and everybody else except Paul) "single" here
means the type of the pointer is T*
as opposed to T(*)[N] for N>1. For Paul the pointer type is always T*
and "pointer to a single..." describes some runtime state, that is,
the pointer's value is currently the address of a single object that
is NOT part of a multi-element array.

can be used to access the
value with the subscripting syntax ip[0].

Sure. But given Paul's understanding of "pointer to single..." any
index other than zero would be illegal. For indices other than zero
the pointer would have to be a "pointer to an array" (to use this
words ... which can be translated to "pointer to an element of an
array" in proper-speak).

A pointer to int points to (wait for it...) an int.

Sure it does. What people need to realize is that Paul is stuck in a
certain mindset. In this mindset "pointing to..." and a pointer
expression's type don't correlate much. This becomes obvious with his
broken finger/banana/bunch-of-bananas analogy (broken because a finger
has no type w.r.t. what it can point to). Especially the "an array is
just a pointer [with additional magical type info w.r.t. array size]"-
way-of-thinking is what makes his mental model of arrays and pointers
more complicated than it has to be. Different mental model. Different
terminology. And any attempt to make him understand this proved to be
futile. I'm actually surprized that people still respond to him. It's
all been said before.

There is nothing broken about the banana analogy.

Another example is a box of strawberries, if you point to a strawberry in a
box , you canot do so without also pointing at the box of strawberries. To
say you are pointing at strawberry#51, for example, is simply being
specific about which strawberry you are pointing too, you are also pointing
at the box of strawberries when you point to strawberry51.

That is not the general consensus.
If someone is called as a witness in a crime court and they show him a group
of 5 people
and ask him to tell which of them he has seen at the location of the crime.
Then, if he only points his finger, the case is not yet clear.
Because the pointer is untyped.
But if the witness says, "that’s him", the pointer become typed.
No one will say that it is not conclusive, because he was pointing to the
whole group.

Similarly, if you point to strawberry#51 and say "That strawberry is
rotten",
nobody will assume that the whole box is rotten.

 

[Thomas David Rivers]

Yes I agree.

That's great!

So - now, given our understanding that an lvalue reference
to an array name is converted to be a pointer to the first element
of the array, we can examine things like array indexing (which
is really cool) and multiple dimension arrays...

I propose we take a look at array indexing... would that be interesting?

- Dave Rivers -

 

[Paul]

That's great!

So - now, given our understanding that an lvalue reference
to an array name is converted to be a pointer to the first element
of the array, we can examine things like array indexing (which
is really cool) and multiple dimension arrays...

I propose we take a look at array indexing... would that be interesting?

I agree given that an array name is converted to a pointer to the array and
not ONLY to a first element of the array.
Can you aggree that an array name converted to a pointer points to an array?

 

[Paul]

"Paul" wrote in message news:[email protected]...

Paul said:
[...]

In C++ a pointer to a single value of type T

Keep in mind that "pointer to a single..." has a special meaning for
Paul. While for you (and everybody else except Paul) "single" here
means the type of the pointer is T*
as opposed to T(*)[N] for N>1. For Paul the pointer type is always T*
and "pointer to a single..." describes some runtime state, that is,
the pointer's value is currently the address of a single object that
is NOT part of a multi-element array.

can be used to access the
value with the subscripting syntax ip[0].

Sure. But given Paul's understanding of "pointer to single..." any
index other than zero would be illegal. For indices other than zero
the pointer would have to be a "pointer to an array" (to use this
words ... which can be translated to "pointer to an element of an
array" in proper-speak).

A pointer to int points to (wait for it...) an int.

Sure it does. What people need to realize is that Paul is stuck in a
certain mindset. In this mindset "pointing to..." and a pointer
expression's type don't correlate much. This becomes obvious with his
broken finger/banana/bunch-of-bananas analogy (broken because a finger
has no type w.r.t. what it can point to). Especially the "an array is
just a pointer [with additional magical type info w.r.t. array size]"-
way-of-thinking is what makes his mental model of arrays and pointers
more complicated than it has to be. Different mental model. Different
terminology. And any attempt to make him understand this proved to be
futile. I'm actually surprized that people still respond to him. It's
all been said before.

There is nothing broken about the banana analogy.

Another example is a box of strawberries, if you point to a strawberry in a
box , you canot do so without also pointing at the box of strawberries. To
say you are pointing at strawberry#51, for example, is simply being
specific about which strawberry you are pointing too, you are also pointing
at the box of strawberries when you point to strawberry51.

That is not the general consensus.
If someone is called as a witness in a crime court and they show him a group
of 5 people
and ask him to tell which of them he has seen at the location of the crime.
Then, if he only points his finger, the case is not yet clear.
Because the pointer is untyped.
But if the witness says, "that’s him", the pointer become typed.
No one will say that it is not conclusive, because he was pointing to the
whole group.

Similarly, if you point to strawberry#51 and say "That strawberry is
rotten",
nobody will assume that the whole box is rotten.

 

[Paul]

A pointer to an array of integer objects is of type int*.

Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]

No I am not wrong, int* can point to a single int or an array of
integers as shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with
the subscripting syntax T[N], where N is the, zero based, Nth element
of the array.

In C++ a pointer to a single value of type T can be used to access the
value with the subscripting syntax ip[0]. A pointer to int points to
(wait for it...) an int.

Well, to be totally fair, there is one occurrence where this is not
true:

int* p = new int[0];

p points to an array with no elements and p doesn't point to an int.

'p' is still a *pointer to an* 'int' even if it is not *pointing to* an
'int'.

No you are an idiot. 'p''s type has nothing to do with what it points to.

Also:

int* p = 0;

'p' is still a *pointer to an* 'int' even though it is not *pointing to*
an 'int'.

No you are confused between what it's type is and what it points to.

Subtle but important terminology. One term describes a compile time
concept whilst the other term describes a runtime concept.

Subtle but important terminology includes the word "type". You are an idiot.

 

[Paul]

[snip]

So what, in your mind, is the object referred to by the C++ standard as
a
non modifiable object of array type?

Exactly where in the C++ standard is the phrase "non modifiable
object of array type"? I could not find it in either the 1998
standard or the 2003 revision.

Section 8.3.4 Arrays

5 [ Note: conversions affecting expressions of array type are described
in
4.2. Objects of array types cannot be modified, see 3.10. -end note ]
§

An example of the second sentence of the note is that the assignment
statement

x = y;

is not allowed when x and y are arrays, say declared with

int x[3], y[3];

The object of array type that cannot be modified is the one that
contains the sub-objects that are the array elements. In the
example, it is the object named x, containing 3 sub-objects of type
int. In general, C++ operators do not manipulate an entire array as
a unit.

Similarly, assigning to a dereferenced pointer to an array is not
allowed, as in

*px = y

where in addition to the declaration of x and y above, px is declared
with

int (*px)[3] = &x;


The sections of the C++ standard cited in the above note give the
details of why assigning to an array type is not allowed. Paragraph
1 of section 4.2 (Array-to-pointer conversion) is:

An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.

Note that the result of an array-to-pointer conversion is an rvalue
of type pointer.

The first two paragraphs of 3.10 (Lvalues and rvalues) are

Every expression is either an lvalue or an rvalue.

An lvalue refers to an object or function. Some rvalue expressions
--- those of class or cv-qualified class type --- also refer to
objects.

Given the declaration

int z;

the result of the expression z is an lvalue that refers to the object
where the value of the variable z is stored.

Because a pointer is not of a class or cv-qualified class type, the
rvalue result of array-to-pointer conversion does not refer to an
object. In a assignment the left operand needs to refer to an object,
the one whose value is replaced with that of the right operand of the
assignment.

What did you have for breakfast?

A pointer is not a class , period.

 

[Paul]

[snip]

A pointer to an array of integer objects is of type int*.

Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]

No I am not wrong, int* can point to a single int or an array of
integers as shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with
the subscripting syntax T[N], where N is the, zero based, Nth element
of the array.

In C++ a pointer to a single value of type T can be used to access the
value with the subscripting syntax ip[0]. A pointer to int points to
(wait for it...) an int.

In the expression :
int* p_arr= new int[66];
the pointer points to an array of integers, not a single integer.

Yes you could say that the pointer only points to one single integer, but
it also points to the array of integers.
To suggest that it points to one single integer and only one single
integer is incorrect, narrow minded and ignorant of the fact that it
actually points to an array of integers.

Can you say "straw man"? There, I knew you could.

I'm sorry I do not understand you , is this something similar to the wicker
man?

 

[Michael Doubez]

On 2011-05-30 16:08:47 -1000, Paul said:
On 29/05/2011 20:43, Paul wrote:
[snip]
A pointer to an array of integer objects is of type int*.
Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]
Well, to be totally fair, there is one occurrence where this is not
true:
int* p = new int[0];
p points to an array with no elements and p doesn't point to an int.

'p' is still a *pointer to an* 'int' even if it is not *pointing to* an
'int'.

We agree but you nonetheless need the value of the pointer to delete
he array even though it doesn't *actually* point to an int.

Well, just nitpicking.

 

[Paul]

A pointer to an array of integer objects is of type int*.

Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'.

[snip]

No I am not wrong, int* can point to a single int or an array of
integers as shown :

int* p_arr= new int[66];

In C++ a pointer to an array of T's is used to access the array with
the subscripting syntax T[N], where N is the, zero based, Nth element
of the array.

In C++ a pointer to a single value of type T can be used to access the
value with the subscripting syntax ip[0]. A pointer to int points to
(wait for it...) an int.

Well, to be totally fair, there is one occurrence where this is not
true:

int* p = new int[0];

p points to an array with no elements and p doesn't point to an int.

'p' is still a *pointer to an* 'int' even if it is not *pointing to*
an 'int'.

No you are an idiot. 'p''s type has nothing to do with what it points to.

The confusion is all yours as you cannot accept that a pointer of type
'int*' can never point to an array; it can only ever point to an 'int'
object (or no object at all). If a pointer of type 'int*' is pointing to
the first element of an 'int' array then that pointer can be passed to
delete[] to deallocate the array.

If a pointer points-to the first element of an array, it points to the
array.
An int* can be null, point to an int or point to an array of ints.

Again the confusion is all yours. Here the type of 'p' is "pointer to an
int" however it is not (at runtime) pointing to an 'int' object.

Its TYPE is pointer to int TYPE.
p is not a pointer to a single int if it points to an array of them.

"Types" only exist at compile time (ignoring RTTI) so are the "compile
time concept" I was referring to; objects on the other hand only exist at
runtime so are the "runtime concept" I was referring to. Pay attention.

Again with the insults; your "debating" skills are amazing.

This debate has been had before and you cannot accept the obvious.
int* p = new arr[66];

If the allocation succeeds, p points to an array of int objects.
You are of the opinion that p does not point to an array of integers but
only to one single integer.

 

[gwowen]

This debate has been had before and you cannot accept the obvious.
int* p = new arr[66];

If the allocation succeeds, p points to an array of int objects.
You are of the opinion that p does not point to an array of integers but
only to one single integer.

"When the allocated object is an array (that is, the direct-new-
declarator
syntax is used or the new-type-id or type-id denotes an array
type), the
new-expression yields a pointer to the initial element (if any) of
the array."
[Some standard or other, 5.3.4:5]

 

[Thomas David Rivers]

I agree given that an array name is converted to a pointer to the
array and not ONLY to a first element of the array.
Can you agree that an array name converted to a pointer points to an
array?

Oh - I'm sorry, but I can't, and when we get into how indexing works and
how arrays with multiple dimensions work I hope to motivate the argument
of why that isn't a correct characterization... but, that comes later.

That is, we need to be quite careful with the types of things; or the entire
mess comes crumbling down.

You see - there is the idea of a pointer to an array, and that is quite
different
from the idea of a pointer to an element of an array. One can imagine
that would
have to be the case, or else you could not distinguish between the
entire array
and an element of the array... which becomes paramount in the definition of
the indexing operation.

The language definition is quite precise that a pointer to an element of
an array
is nothing more than that; a pointer to one element of the array.
Since this could
easily be confused with the (real, although not yet
discussed/introduced) idea of
a pointer to an array then we have to stick with the language definition.

Again, when we consider how indexing works - this will become a very
important
distinction.

But, to movitate this, and "jump ahead" a little, this declaration

int (*ap)[5];

is a pointer to an array of 5 `int' elements. Those are the terms
reserved
by the language definition. "ap" is actually is a separate object (a
separate "box")
that points to 5 other `int' objects, thus "ap" is a pointer to an array
of 5 `int' elements.
That is very different from:

int *ip;
int array[5];

ip = array;


In this situation, it is very clear that `ip' is a pointer to an `int',
and that
it happens to point to the first `int' alement of array (because of the
rules
we've already discussed), but that's as far as the language definition
carries us.

But, "ip" is a box that can contain the location of an `int' box. "ap"
is a box
that can contain the location of an array of 5 `int' boxes... so, "ap"
and "ip"
are quite different types, different "kinds" of boxes.

And, as I mentioned before - that becomes very important when indexing
is defined.

So, while there may be other terms we could use, "pointer to an array"
has already
been taken by the language definition and is very well defined.

I could see myself throwing around some of the other words that have been
mentioned here (saying that, for example, a pointer points "into" an array.)
But those are colloquialisms without any formal definition... so, they
can mean
just about whatever anyone would like them to mean at any time, which makes
talking about them kinda difficult.

Maybe we could coin some new terms??? I would be happy to discuss them,
but I think they are outside the bounds of the C/C++ language definition.

(That is not to say that in some other programming language, or other
situation,
they would not be appropriate - I just believe that is not the correct
characterization
for C/C++, and certainly not in the spirit of the language definitions.)

- Dave Rivers -

 

[Paul]

Oh - I'm sorry, but I can't, and when we get into how indexing works and
how arrays with multiple dimensions work I hope to motivate the argument
of why that isn't a correct characterization... but, that comes later.

That is, we need to be quite careful with the types of things; or the
entire
mess comes crumbling down.

You see - there is the idea of a pointer to an array, and that is quite
different
from the idea of a pointer to an element of an array. One can imagine
that would
have to be the case, or else you could not distinguish between the entire
array
and an element of the array... which becomes paramount in the definition
of
the indexing operation.

I disagree with you. The following is a pointer to an array of integers:

int arr[10];
int* p_arr = arr;

The pointer TYPE is pointer to integer, but what it points to is an array of
integers.

The language definition is quite precise that a pointer to an element of
an array
is nothing more than that; a pointer to one element of the array. Since
this could
easily be confused with the (real, although not yet discussed/introduced)
idea of
a pointer to an array then we have to stick with the language definition.

Again, when we consider how indexing works - this will become a very
important
distinction.

But, to movitate this, and "jump ahead" a little, this declaration

int (*ap)[5];

is a pointer to an array of 5 `int' elements. Those are the terms
reserved
by the language definition. "ap" is actually is a separate object (a
separate "box")
that points to 5 other `int' objects, thus "ap" is a pointer to an array
of 5 `int' elements.
That is very different from:

int *ip;
int array[5];

ip = array;


In this situation, it is very clear that `ip' is a pointer to an `int',
and that
it happens to point to the first `int' alement of array (because of the
rules
we've already discussed), but that's as far as the language definition
carries us.

But, "ip" is a box that can contain the location of an `int' box. "ap" is
a box
that can contain the location of an array of 5 `int' boxes... so, "ap" and
"ip"
are quite different types, different "kinds" of boxes.

They are different types but the both store the same address, the initial
element of the array.
'ap' does not contain the location of five boxes , it contains only the
location of the initial box, as does 'ip'.

And, as I mentioned before - that becomes very important when indexing
is defined.

So, while there may be other terms we could use, "pointer to an array" has
already
been taken by the language definition and is very well defined.

I was not using the term "pointer to an array" as defined by the language
definition. I was using it for what it means to me. If the language defines
"pointer to an X" to mean "pointer of type pointer to X" then lets use a
different term.
'ip' points to an array of integer objects, it is of type "pointer to int"

I could see myself throwing around some of the other words that have been
mentioned here (saying that, for example, a pointer points "into" an
array.)
But those are colloquialisms without any formal definition... so, they can
mean
just about whatever anyone would like them to mean at any time, which
makes
talking about them kinda difficult.

Maybe we could coin some new terms??? I would be happy to discuss them,
but I think they are outside the bounds of the C/C++ language definition.

(That is not to say that in some other programming language, or other
situation,
they would not be appropriate - I just believe that is not the correct
characterization
for C/C++, and certainly not in the spirit of the language definitions.)

Consider the following:

void* p1 = (void*)new int;
void* p2 = (void*)new int[55];

p1 points to a single integer.
p2 points to an array of integers.

This is what I mean when I say 'ip' is a pointer to an array. I don't mean
it's type, I am talking about what it points to.


In C++ a pointer type int* can point to:
A single integer or an array of integers.
Null.
Some random uninitialised memory.


Remember what our definition of an array is. Just a sequence of objects in
memory and nothing more.
If that sequence of objects are int types then the pointer to point to them
must be of type int*.
Also we agreed that 'arr' is a name trhat refers to this array of objects so
with:
int arr[66];
int* p = arr;

p is now a pointer that refers to the same array of integer objects that
'arr' referred to.