An array is just a pointer

[Paul]

I have this array:

int (*array)[4] = new int[4][4];
++array;
array[-1][3] = 4;

Is this an array? Or is it not an array?

Is what an array or not?

The entity I indexed with the expression array[-1][3], wtf do you think i
mean?

What you allocated is an array. The
variable "array" is a pointer, not an array (as sizeof(array)
will clearly show).

Also I have another array:

int* arr1 = new int[12];
arr1[0] = 33;
int* arr2 = new(++arr1) int[11];
std::cout<< arr2[-1];

I'm not sure, but I think that last line has undefined behavior.
The array new operator returns a pointer to the *first* element
of an array.

Its not undefined at all, it's defined in the C++ standard as :
*((arr2)+(-1))

Again, is what an array or just a pointer.

Again, the entity I indexed with the expression arr2[-1], wtf do you think?

All of the named
variables in your code are pointers, not arrays.

So you think that when I index the array with arr2[-1], I do not index an
array?

Strange how it seems to return the correct values ..hmmm

An int* is a pointer. It may point to the first element of an
array (or anywhere inside an array, for that matter), but it is
and remains a pointer to a single int.

No it can point to an array. The C++ standard clearly states that :
"the newexpression yields a pointer to the initial element (if any) of the
array. [Note: both new int and new int[10] have type int* and the type of
new int[10] is int (*)[10]. ]"


Strange how you seem to have changed colors on this , it doesn't seem that
long ago that I stuck in to support you when you were having the exact same
argument with Leigh. And you said
Voila! when I posted code to support you.

 

[Paul]

Maybe the following will help you understand the semantic
differences
involved:

int main()
{
int* p1 = new int[42]; // 'p1' is a pointer to the first element
of an
array
int (*p2)[42] = new int[1][42]; // 'p2' is a pointer to an array
}

This is a clear indication of how screwed up you are. Please read the
following :

"the newexpression yields a pointer to the initial element (if any)
of the
array. [Note: both new int and new int[10] have type int* and the
type
of new int[10] is
int (*)[10]. ]"


The standards define both of these types to be pointers to the array,
they are just different *types* of pointer.


No; for the final time: int* is not a pointer to an array; int* is a
pointer to a scalar; the Standard clearly states "the new-expression
yields a pointer to the initial element (if any) of the array"; it
doesn't state that "the new-expression yields a pointer to the array".


Err no your nonsense is becoming beyond belief .
A pointer to the first element *IS* a pointer to the array.

The standards states clearly that both int* and int(*)[10] are pointers
to the first element. There is no difference in what these pointers
point to. You must think int(*)[10] is an array of pointers or
something
, *shakes head* no I don't know what nonsense you think.


Yes everything seems like nonsense to you as you are either unable or
unwilling to be get a firm technical grasp on C++ matters.

PROVEN WRONG!

Proven wrong about what exactly? Where is this proof?

Wrong with your nonsense about pointer types and what they point to . Above
^^^^^^^^^^^^^^^

 

[Paul]

[...]
Err no "a pointer to the first element of an array" means exactly the
same
thing as "a pointer to an array".

Since when? Since when is the first element of an array the same
thing as the array?

Err since it was born as part of the array. If it points to the first
element of the array how can it not point to the array?

 

[Paul]

news:[email protected]...

On 17/03/2011 21:45, Paul wrote:

[...]

This means that
int* x = new int[12];
Yields a pointer to an array. Not to *any* memory location.
x is a pointer to a scalar not a pointer to an array; the scalar just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any) of
the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.

What are you talking about , if its pointing ot the first element of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

[...]

Obviously the function parameter should be char p[].

When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.

In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.

I already have and your point is?

 

[Peter Remmers]

Am 18.03.2011 01:01, schrieb Paul:

Am 17.03.2011 23:00, schrieb Paul:

You don't seem to be clear, maybe you don't like committing yourself to
say
if it is an array or if its not. Let me explain further:

void foo(char p[]){std::cout<< p;}

foo("Is this an array?");

This gives a warning, as the type of the string literal is "const
char[18]", and it only converts to "char*" for compatibility with C.
foo's parameter is lacking the const.

Is an array passed to the function or not? Is an array processed by cout
or
not?

You pass a string literal, which is indeed an unnamed char array, but what
foo receives is a "char*", and I'm pretty sure cout's "operator<<(char*)"
overload is called, which means it also receives a char pointer.

As far as I know (haven't noticed any difference to date), these two are
completely equivalent, and differ only in syntax:
void foo(char p[]) { ... }
void foo(char *p) { ... }

If I print sizeof(p) in foo, I get "4" in both variants on my machine.
Even if you do this:

void foo(char p[18]) { ... }

you still get "4" for sizeof(p).

Only something like this will give "18":

void foo(char (&p)[18]) { .. }

I don't need to know the length of the array because I passed a unlll
terminated string.

Well, it's not like I haven't mentioned null-terminated strings below.

You still seem a bit unclear whether or not the array is received by
function, you state the function receives a char*(not an array). The way you
said it seemed to imply what I put in brackets.

Yes, it receives a pointer to one single lonely int, and it cannot
possibly know whether that poor little int has any neighbours and if so,
how many. The function can go ahead and assume anything it wants, and
try to access as many presumed neighbours as it likes, but unless the
programmer encodes their knowledge of the code outside the function into
these accesses, it is all but certain to be UB.

Am I correct in assuming you think the array I passed is not an array
(inside the function) because i passed a pointer to it?

Yes, inside the function there is only a pointer to one int, which does
indeed have neighbours, but that knowledge gets lost through the
function call.

You think the array is not an array anymore for some reason?

The array is still there, but the knowledge about it does not cross the
point of the function invocation.
It is actually the same with operator new, just reversed. Operator new
creates an array, but it returns a pointer to only one int. From that
pointer alone you would not know how many elements follow the int. You
only know the secret number because you told operator new how many
elements you want, and you can only assume it followed your request.

An array can be converted to a pointer, and once the conversion is done,
the information about the number of elements is lost.
If you pass such a pointer to some function, the receiving side will only
see a pointer to one element and can only speculate as to how many
elements, if any, follow (or even precede!) the element that it points to.
That's why, for functions that are to operate on an array of elements,
usually the length must be passed in a separate parameter. For functions
that receive char*, the assumption is usually that it is a zero-terminated
string, and so a length is not necessary.

The story is a bit different for templates. An example is the _countof
macro I mentioned elsewhere.


An array is an array, and a pointer is a pointer. Maybe you think
"identifies an array" is the same as "points to an array"?

There you go, now you now my position (as if it wasn't clear before). Go
ahead and look down on me, like you do with everyone who does not share
your weird beliefs. I will bear it like a man.

Well not really you still didn't really make yourself clear. You said an
array was passed but the function received a pointer.

Its generally known as pass by reference. And you pass a pointer to the
array, if I dereference that pointer I access the arrays data for example:

void voo(char* p){
char c = p[0];
}


Do you agree that I'm indexing the array here, or do you somehow think there
is no array?

I agree you're indexing the array there. But you only do that indirectly
through pointer arithmetic on "p". And you do that with the assumption
that p indeed points to an element of an array and that element has the
neighbors you're trying to access.
Actually, in this case a single int would really suffice, and your
access is well defined, as you're using an offset of zero (barring of
course things like NULL pointers and invalid pointers).

Peter

 

[Paul]

Am 18.03.2011 01:01, schrieb Paul:

message

Am 17.03.2011 23:00, schrieb Paul:
You don't seem to be clear, maybe you don't like committing yourself
to
say
if it is an array or if its not. Let me explain further:

void foo(char p[]){std::cout<< p;}

foo("Is this an array?");

This gives a warning, as the type of the string literal is "const
char[18]", and it only converts to "char*" for compatibility with C.
foo's parameter is lacking the const.

Is an array passed to the function or not? Is an array processed by
cout
or
not?

You pass a string literal, which is indeed an unnamed char array, but
what
foo receives is a "char*", and I'm pretty sure cout's
"operator<<(char*)"
overload is called, which means it also receives a char pointer.

As far as I know (haven't noticed any difference to date), these two
are
completely equivalent, and differ only in syntax:
void foo(char p[]) { ... }
void foo(char *p) { ... }

If I print sizeof(p) in foo, I get "4" in both variants on my machine.
Even if you do this:

void foo(char p[18]) { ... }

you still get "4" for sizeof(p).

Only something like this will give "18":

void foo(char (&p)[18]) { .. }

I don't need to know the length of the array because I passed a unlll
terminated string.

Well, it's not like I haven't mentioned null-terminated strings below.

You still seem a bit unclear whether or not the array is received by
function, you state the function receives a char*(not an array). The way
you
said it seemed to imply what I put in brackets.

Yes, it receives a pointer to one single lonely int, and it cannot
possibly know whether that poor little int has any neighbours and if so,
how many. The function can go ahead and assume anything it wants, and try
to access as many presumed neighbours as it likes, but unless the
programmer encodes their knowledge of the code outside the function into
these accesses, it is all but certain to be UB.

Am I correct in assuming you think the array I passed is not an array
(inside the function) because i passed a pointer to it?

Yes, inside the function there is only a pointer to one int, which does
indeed have neighbours, but that knowledge gets lost through the function
call.

You think the array is not an array anymore for some reason?

The array is still there, but the knowledge about it does not cross the
point of the function invocation.
It is actually the same with operator new, just reversed. Operator new
creates an array, but it returns a pointer to only one int. From that
pointer alone you would not know how many elements follow the int. You
only know the secret number because you told operator new how many
elements you want, and you can only assume it followed your request.

An array is a pointer in most situations and it's complete nonsense to
suggest its not an array because its a pointer. That's my opinion, I
don't
know yours because you didn't make your opinion too clear.
An array can be converted to a pointer, and once the conversion is
done,
the information about the number of elements is lost.
If you pass such a pointer to some function, the receiving side will
only
see a pointer to one element and can only speculate as to how many
elements, if any, follow (or even precede!) the element that it points
to.
That's why, for functions that are to operate on an array of elements,
usually the length must be passed in a separate parameter. For
functions
that receive char*, the assumption is usually that it is a
zero-terminated
string, and so a length is not necessary.

The story is a bit different for templates. An example is the _countof
macro I mentioned elsewhere.

As for Leigh and co's opinion about arrays not being arrays because
they
are
pointers, well that's obviously complete nonsense, I hope you don't
share
their opinion :-S

An array is an array, and a pointer is a pointer. Maybe you think
"identifies an array" is the same as "points to an array"?

There you go, now you now my position (as if it wasn't clear before).
Go
ahead and look down on me, like you do with everyone who does not share
your weird beliefs. I will bear it like a man.

Well not really you still didn't really make yourself clear. You said an
array was passed but the function received a pointer.

Its generally known as pass by reference. And you pass a pointer to the
array, if I dereference that pointer I access the arrays data for
example:

void voo(char* p){
char c = p[0];
}


Do you agree that I'm indexing the array here, or do you somehow think
there
is no array?

I agree you're indexing the array there.

Good, but I see a "but" coming, so before I read the rest of this. Let me
tell you this , I *am* indexing the array.

But you only do that indirectly through pointer arithmetic on "p".

It doesn't matter how I do it, I am definately indexing an array, you even
agree with that.

And you do that with the assumption that p indeed points to an element of
an array and that element has the neighbors you're trying to access.

p points to an array yes.

Actually, in this case a single int would really suffice, and your access
is well defined, as you're using an offset of zero (barring of course
things like NULL pointers and invalid pointers).

So you agree that term p[0] indexes an array , right we can now move on....
Does the two array access expressions yield the same array indices or not?
:
p[0];
++p;
p[-1];

 

[Stuart Golodetz]

news:[email protected]...

On 17/03/2011 21:45, Paul wrote:
[...]
This means that
int* x = new int[12];

Yields a pointer to an array. Not to *any* memory location.

x is a pointer to a scalar not a pointer to an array; the scalar just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any)
of the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.

What are you talking about , if its pointing ot the first element of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org/

b) Consider the difference between types and values. A variable of type
'int *' is a pointer to an int, regardless of the value it contains, but
it may point at either an individual int, or an element of an array of
ints, or indeed somewhere completely invalid. To say that a variable of
type 'int *' that contains the address of the first element of an array
of ints 'points at the array' is to some extent an understandable
colloquialism, but it's imprecise. The pointer points at the first int
in the array, because by type it is a pointer to an (one, singular) int.

The key point is that whatever *value* I store in the pointer at
runtime, I can't change its *type* (types are compile-time entities). In
the following, both x and y have the same type:

int *x = new int;
int *y = new int[23];

They are both pointers to a single int. At runtime, x contains the
address of an individual int, and y contains the address of an int that
happens to be the first element of an int array. If you want to
colloquially describe that situation by saying 'y points to the array',
then that's up to you (most people would probably understand what you
meant), but formally speaking it's not the case.

Regards,
Stu

[...]

Obviously the function parameter should be char p[].

When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.

In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.

I already have and your point is?

 

[Stuart Golodetz]

[...]
Err no "a pointer to the first element of an array" means exactly the
same
thing as "a pointer to an array".

Since when? Since when is the first element of an array the same
thing as the array?

Err since it was born as part of the array. If it points to the first
element of the array how can it not point to the array?

It's all to do with types. The same value can mean different things
depending on how you're interpreting it.

Suppose i is an int and p is an int*. Both contain the value 23 (say).
But the two variables are not the same: p points at the int at memory
location 23, whereas i only contains a number. i doesn't point anywhere,
because it's an int.

Now suppose x is of type int* and y is of type int (*)[9]. Both contain
the value 1984 (say). But the two variables are not the same: x points
at the int at memory location 1984, whereas y points at the array of 9
ints at memory location 1984. They point to the same place (1984), but
they're pointing at different things, because their *types* are
different - what they are pointing at depends not on the values they
contain, but on their types.

Your contention is that if there is an array starting at memory location
1984 and int *x contains the address 1984, then x 'points to the array'.
In the simple sense of 'hey, there's the array, and x contains what is
effectively a big arrow to where the array begins', this is an
understandable viewpoint, but in terms of its *type*, x points to an int
(the first element of the array).

Bottom line: The *value* x contains is irrelevant; it points to the sort
of entity its *type* tells you it does (in this case, a single int).

Regards,
Stu

 

[Paul]

[...]
Err no "a pointer to the first element of an array" means exactly the
same
thing as "a pointer to an array".

Since when? Since when is the first element of an array the same
thing as the array?

Err since it was born as part of the array. If it points to the first
element of the array how can it not point to the array?

It's all to do with types. The same value can mean different things
depending on how you're interpreting it.

Suppose i is an int and p is an int*. Both contain the value 23 (say). But
the two variables are not the same: p points at the int at memory location
23, whereas i only contains a number. i doesn't point anywhere, because
it's an int.

Now suppose x is of type int* and y is of type int (*)[9]. Both contain
the value 1984 (say). But the two variables are not the same: x points at
the int at memory location 1984, whereas y points at the array of 9 ints
at memory location 1984. They point to the same place (1984), but they're
pointing at different things, because their *types* are different - what
they are pointing at depends not on the values they contain, but on their
types.

Your contention is that if there is an array starting at memory location
1984 and int *x contains the address 1984, then x 'points to the array'.
In the simple sense of 'hey, there's the array, and x contains what is
effectively a big arrow to where the array begins', this is an
understandable viewpoint, but in terms of its *type*, x points to an int
(the first element of the array).

Bottom line: The *value* x contains is irrelevant; it points to the sort
of entity its *type* tells you it does (in this case, a single int).

No it points to, in this case , the first int in an array. It's not a single
int it's an array of int's.
int* x = new int[64];
This creates an array, not a single int. It's nonsense to suggest this
points to a single integer when it obviously points to the first int in an
array.

 

[Paul]

On 17/03/2011 21:45, Paul wrote:

[...]
This means that
int* x = new int[12];

Yields a pointer to an array. Not to *any* memory location.

x is a pointer to a scalar not a pointer to an array; the scalar just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any)
of the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.

What are you talking about , if its pointing ot the first element of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org

b) Consider the difference between types and values. A variable of type
'int *' is a pointer to an int, regardless of the value it contains, but
it may point at either an individual int, or an element of an array of
ints, or indeed somewhere completely invalid. To say that a variable of
type 'int *' that contains the address of the first element of an array of
ints 'points at the array' is to some extent an understandable
colloquialism, but it's imprecise. The pointer points at the first int in
the array, because by type it is a pointer to an (one, singular) int.

I know about different types , look at the code in my initial post.

The key point is that whatever *value* I store in the pointer at runtime,
I can't change its *type* (types are compile-time entities). In the
following, both x and y have the same type:

int *x = new int;
int *y = new int[23];

They are both pointers to a single int.

No this is wrong, y is a pointer to the first element in an array of ints,
not a single int.
You are correct to say they are the same types but they point to different
entities.

At runtime, x contains the address of an individual int, and y contains the
address of an int that happens to be the first element of an int array. If
you want to colloquially describe that situation by saying 'y points to the
array', then that's up to you (most people would probably understand what
you meant), but formally speaking it's not the case.

Formally speaking it is exactly the case that y points to an array. It's
techincally incorrect to suggest it doesn't because the standards say that
it points to the initial element *of an array*.

Regards,
Stu

[...]
Obviously the function parameter should be char p[].

When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.

In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.

I already have and your point is?

 

[Martijn van Buul]

* Paul:

Err no your nonsense is becoming beyond belief .

Not again :-/

 

[Stuart Golodetz]

[...]
Err no "a pointer to the first element of an array" means exactly the
same
thing as "a pointer to an array".

Since when? Since when is the first element of an array the same
thing as the array?


Err since it was born as part of the array. If it points to the first
element of the array how can it not point to the array?

It's all to do with types. The same value can mean different things
depending on how you're interpreting it.

Suppose i is an int and p is an int*. Both contain the value 23 (say).
But the two variables are not the same: p points at the int at memory
location 23, whereas i only contains a number. i doesn't point
anywhere, because it's an int.

Now suppose x is of type int* and y is of type int (*)[9]. Both
contain the value 1984 (say). But the two variables are not the same:
x points at the int at memory location 1984, whereas y points at the
array of 9 ints at memory location 1984. They point to the same place
(1984), but they're pointing at different things, because their
*types* are different - what they are pointing at depends not on the
values they contain, but on their types.

Your contention is that if there is an array starting at memory
location 1984 and int *x contains the address 1984, then x 'points to
the array'. In the simple sense of 'hey, there's the array, and x
contains what is effectively a big arrow to where the array begins',
this is an understandable viewpoint, but in terms of its *type*, x
points to an int (the first element of the array).

Bottom line: The *value* x contains is irrelevant; it points to the
sort of entity its *type* tells you it does (in this case, a single int).

No it points to, in this case , the first int in an array. It's not a
single int it's an array of int's.
int* x = new int[64];
This creates an array, not a single int. It's nonsense to suggest this
points to a single integer when it obviously points to the first int in
an array.

The first int in an array *is* a single int It's not two ints, three
ints, 64 ints or a million ints. It's a single darn int. The fact that
it may be followed in memory by other ints doesn't alter that fact.

On the other hand, if by "It" in "It's not a single int..." you mean the
array, then I agree with you. Evidently

 

[Stuart Golodetz]

On 17/03/2011 21:45, Paul wrote:

[...]
This means that
int* x = new int[12];

Yields a pointer to an array. Not to *any* memory location.

x is a pointer to a scalar not a pointer to an array; the scalar
just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any)
of the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.


What are you talking about , if its pointing ot the first element of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org

b) Consider the difference between types and values. A variable of
type 'int *' is a pointer to an int, regardless of the value it
contains, but it may point at either an individual int, or an element
of an array of ints, or indeed somewhere completely invalid. To say
that a variable of type 'int *' that contains the address of the first
element of an array of ints 'points at the array' is to some extent an
understandable colloquialism, but it's imprecise. The pointer points
at the first int in the array, because by type it is a pointer to an
(one, singular) int.

I know about different types , look at the code in my initial post.

The key point is that whatever *value* I store in the pointer at
runtime, I can't change its *type* (types are compile-time entities).
In the following, both x and y have the same type:

int *x = new int;
int *y = new int[23];

They are both pointers to a single int.

No this is wrong, y is a pointer to the first element in an array of
ints, not a single int.

Depends on your definition of "single". The first element in an array of
ints is an int (indisputable). The first element is also a singular
entity (that is, there is only one of it). I thus describe it as a
"single int" - it is one, and only one, int.

It is however arguable that you could define "single" to mean "stands
alone in memory, away from any other ints", i.e. this int is a rock, it
is an island. In that sense, my calling the first element of an array a
"single int" might perhaps have a tendency to confuse some people.
Regardless, I intended the first meaning, which I hope I have now
clarified

You are correct to say they are the same types but they point to
different entities.

Depends on what you mean by "point to". Technically speaking, they both
point at an int. One of those ints just happens to be at the start of an
array.

Formally speaking it is exactly the case that y points to an array. It's
techincally incorrect to suggest it doesn't because the standards say
that it points to the initial element *of an array*.

The initial element of an array is not an array. And on that note, I'm
off to play squash Bored already.

Regards,
Stu

[...]
Obviously the function parameter should be char p[].

When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.

In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.

I already have and your point is?

 

[Paul]

On 18/03/2011 00:35, Paul wrote:



[...]
Err no "a pointer to the first element of an array" means exactly the
same
thing as "a pointer to an array".

Since when? Since when is the first element of an array the same
thing as the array?


Err since it was born as part of the array. If it points to the first
element of the array how can it not point to the array?

It's all to do with types. The same value can mean different things
depending on how you're interpreting it.

Suppose i is an int and p is an int*. Both contain the value 23 (say).
But the two variables are not the same: p points at the int at memory
location 23, whereas i only contains a number. i doesn't point
anywhere, because it's an int.

Now suppose x is of type int* and y is of type int (*)[9]. Both
contain the value 1984 (say). But the two variables are not the same:
x points at the int at memory location 1984, whereas y points at the
array of 9 ints at memory location 1984. They point to the same place
(1984), but they're pointing at different things, because their
*types* are different - what they are pointing at depends not on the
values they contain, but on their types.

Your contention is that if there is an array starting at memory
location 1984 and int *x contains the address 1984, then x 'points to
the array'. In the simple sense of 'hey, there's the array, and x
contains what is effectively a big arrow to where the array begins',
this is an understandable viewpoint, but in terms of its *type*, x
points to an int (the first element of the array).

Bottom line: The *value* x contains is irrelevant; it points to the
sort of entity its *type* tells you it does (in this case, a single
int).

No it points to, in this case , the first int in an array. It's not a
single int it's an array of int's.
int* x = new int[64];
This creates an array, not a single int. It's nonsense to suggest this
points to a single integer when it obviously points to the first int in
an array.

The first int in an array *is* a single int It's not two ints, three
ints, 64 ints or a million ints. It's a single darn int. The fact that it
may be followed in memory by other ints doesn't alter that fact.

Its not a single integer though, not if it's the first int in an array of
int's.

On the other hand, if by "It" in "It's not a single int..." you mean the
array, then I agree with you. Evidently

OFC it's there is only one reasonable way to look at it.

int x= new int;
int y = new int[16];

It is technically incorrect to suggest y doesn't point to an array of
integers because technically it does. And also as per the C++ standards it
does because the C++ standards say something like ..new returns a pointer ot
the first element *of the array*.


Look at the following:
a /*Here you see a single a*/
aaaaaaaaaaaaaaaaaaaaaa /*Here you see an array of a's*/


Why do they find it so hard to understand? I honestly cannot believe how
thick anyyone can be, and I don't mean to be nasty or rude towards them but
genuinely I am truly shocked at their low level of intelligence

 

[SG]

I honestly cannot believe how thick anyyone can be, [...]
I am truly shocked at their low level of intelligence

So, you

(1) admit to being an amateur programmer who did not write (much)
C++ code during the past 10 years and admit to have learned C++
from a book called "Turbo C++ 3.0" which appears to have been
released 7 years before the C++ language became an ISO standard,

(2) perceive a bunch of C++ programmers (including professional ones)
to be much dumber than you,

(3) acknowledge the unbelievably low likelihood of everyone of them
being so much dumber than you

and the only conclusion you can draw is that everyone of them must
actually be so much dumber than you, even though (1) and (3) suggest
that you may have missed something in your analysis. It does not look
like self-reflection was part of your analysis.

SG

 

[Paul]

On 18/03/2011 00:42, Paul wrote:




On 17/03/2011 21:45, Paul wrote:

[...]
This means that
int* x = new int[12];

Yields a pointer to an array. Not to *any* memory location.

x is a pointer to a scalar not a pointer to an array; the scalar
just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any)
of the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.


What are you talking about , if its pointing ot the first element of
the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org

b) Consider the difference between types and values. A variable of
type 'int *' is a pointer to an int, regardless of the value it
contains, but it may point at either an individual int, or an element
of an array of ints, or indeed somewhere completely invalid. To say
that a variable of type 'int *' that contains the address of the first
element of an array of ints 'points at the array' is to some extent an
understandable colloquialism, but it's imprecise. The pointer points
at the first int in the array, because by type it is a pointer to an
(one, singular) int.

I know about different types , look at the code in my initial post.

The key point is that whatever *value* I store in the pointer at
runtime, I can't change its *type* (types are compile-time entities).
In the following, both x and y have the same type:

int *x = new int;
int *y = new int[23];

They are both pointers to a single int.

No this is wrong, y is a pointer to the first element in an array of
ints, not a single int.

Depends on your definition of "single". The first element in an array of
ints is an int (indisputable). The first element is also a singular entity
(that is, there is only one of it). I thus describe it as a "single int" -
it is one, and only one, int.

It is however arguable that you could define "single" to mean "stands
alone in memory, away from any other ints", i.e. this int is a rock, it is
an island. In that sense, my calling the first element of an array a
"single int" might perhaps have a tendency to confuse some people.
Regardless, I intended the first meaning, which I hope I have now
clarified

Its not a single int entity if its an array, unless its an size1 array
You suggest the entity pointed to is alway a single int, but that is not the
case with arrays.

Depends on what you mean by "point to". Technically speaking, they both
point at an int. One of those ints just happens to be at the start of an
array.

No one of them points to the initial element of an array. It doesn't just
happen to be the intiall element, it is defined in the C++ standard that it
will point to the initial element.
The other points to a single integer.

I could say you *just happen to be* incorrect about this. *shrug*

The initial element of an array is not an array.

A pointer to the intial element of a array is a pointer to the array. It's
quite simple.

And on that note, I'm off to play squash Bored already.

Glad your going because you make no sense at all.

If you have a row of squash courts together like an array of squash courts,
which many of these places have.
[ ][ ][ ][ ][ ]

Stand outside these squashcourts and look at them as a group and point to
one of those courts with your finger. whilst standing there ask yourself..
Am I pointing to the squash courts(plural) or the squash court(singular)?

THe only reasonable answer is that you are pointing to both.

Regards,
Stu

[...]
Obviously the function parameter should be char p[].

When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.

In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.

I already have and your point is?

 

[Paul]

On 18/03/2011 01:04, Paul wrote:

So you agree that term p[0] indexes an array , right we can now move
on....
Does the two array access expressions yield the same array indices or
not?
:
p[0];
++p;
p[-1];

Negative subscripts are fine in pointer arithmetic but not when indexing
an array so those two pointer deferences are fine and do refer to the same
object.

But these two pointer dereferences are indexing an array.

Again: a pointer is not an array and array is not a pointer.

This definitive distinction between pointer and array that you are trying to
make is a falsity.
I am using the pointer to index an array.

 

[Paul]

I honestly cannot believe how thick anyyone can be, [...]
I am truly shocked at their low level of intelligence

So, you

(1) admit to being an amateur programmer who did not write (much)
C++ code during the past 10 years and admit to have learned C++
from a book called "Turbo C++ 3.0" which appears to have been
released 7 years before the C++ language became an ISO standard,

You think there is something wrong with learning C++ with Turbo C++ 3.0( or
whatever version it was)?
So everyone who learned C++ pre-standards , are crap programmers IYO?

(2) perceive a bunch of C++ programmers (including professional ones)
to be much dumber than you,

Well that's how it appears to be doesn't it

 

[Stuart Golodetz]

On 18/03/2011 04:55, Paul wrote:

On 18/03/2011 00:42, Paul wrote:






On 17/03/2011 21:45, Paul wrote:

[...]
This means that
int* x = new int[12];

Yields a pointer to an array. Not to *any* memory location.

x is a pointer to a scalar not a pointer to an array; the scalar
just
happens to be the first element of an array.

You are wrong to say that its not a pointer to the array ref C++
standards:
"the newexpression yields a pointer to the initial element (if any)
of the
array."

Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.


What are you talking about , if its pointing ot the first element
of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.

a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org

b) Consider the difference between types and values. A variable of
type 'int *' is a pointer to an int, regardless of the value it
contains, but it may point at either an individual int, or an element
of an array of ints, or indeed somewhere completely invalid. To say
that a variable of type 'int *' that contains the address of the first
element of an array of ints 'points at the array' is to some extent an
understandable colloquialism, but it's imprecise. The pointer points
at the first int in the array, because by type it is a pointer to an
(one, singular) int.

I know about different types , look at the code in my initial post.

The key point is that whatever *value* I store in the pointer at
runtime, I can't change its *type* (types are compile-time entities).
In the following, both x and y have the same type:

int *x = new int;
int *y = new int[23];

They are both pointers to a single int.

No this is wrong, y is a pointer to the first element in an array of
ints, not a single int.

Depends on your definition of "single". The first element in an array
of ints is an int (indisputable). The first element is also a singular
entity (that is, there is only one of it). I thus describe it as a
"single int" - it is one, and only one, int.

It is however arguable that you could define "single" to mean "stands
alone in memory, away from any other ints", i.e. this int is a rock,
it is an island. In that sense, my calling the first element of an
array a "single int" might perhaps have a tendency to confuse some
people. Regardless, I intended the first meaning, which I hope I have
now clarified

Its not a single int entity if its an array, unless its an size1 array

You suggest the entity pointed to is alway a single int, but that is not
the case with arrays.

You are correct to say they are the same types but they point to
different entities.

Depends on what you mean by "point to". Technically speaking, they
both point at an int. One of those ints just happens to be at the
start of an array.

No one of them points to the initial element of an array. It doesn't
just happen to be the intiall element, it is defined in the C++ standard
that it will point to the initial element.
The other points to a single integer.

I could say you *just happen to be* incorrect about this. *shrug*

At runtime, x contains the address of an individual int, and y
contains the address of an int that happens to be the first element of
an int array. If you want to colloquially describe that situation by
saying 'y points to the array', then that's up to you (most people
would probably understand what you meant), but formally speaking it's
not the case.

Formally speaking it is exactly the case that y points to an array.
It's
techincally incorrect to suggest it doesn't because the standards say
that it points to the initial element *of an array*.

The initial element of an array is not an array.

A pointer to the intial element of a array is a pointer to the array.
It's quite simple.

And on that note, I'm off to play squash Bored already.

Glad your going because you make no sense at all.

If you have a row of squash courts together like an array of squash
courts, which many of these places have.
[ ][ ][ ][ ][ ]

Stand outside these squashcourts and look at them as a group and point
to one of those courts with your finger. whilst standing there ask
yourself.. Am I pointing to the squash courts(plural) or the squash
court(singular)?

THe only reasonable answer is that you are pointing to both.

No; "pointing to an array of squash courts" is different to "a pointer
to an array of squash courts". This subtle difference is the cause of
your misunderstanding IMO.

/Leigh

The subtle difference is between the following two definitions:

1) For p to point to x, p must contain the address of x.

2) For p to point to x, p must not only contain the address of x, p must
also be of the correct type.

Consider:

#include <iostream>

int main()
{
int a[3];
int *p = &a[0]; // or just 'a'
int (*q)[3] = &a;
std::cout << p << ' ' << q << '\n';
return 0;
}

This prints out the same value twice -- &a[0] and &a have the same
*value*, but different *type*. By definition (1), both p and q point to
a. By definition (2), only q points to a, because p's type dictates that
it points to an int.

One can define "points to" either way (indeed any way one likes), but
definition (2) highlights that there is a difference between the way in
which p and q "point to" a, whereas definition (1) does not. For the
purposes of being precise when there may be ambiguity involved,
definition (2) thus appears preferable in more formal discussion. PMMV
(Paul's mileage may vary).

 

[Stuart Golodetz]

On 18/03/2011 13:44, Leigh Johnston wrote:

No; "pointing to an array of squash courts" is different to "a pointer
to an array of squash courts". This subtle difference is the cause of
your misunderstanding IMO.

/Leigh

The subtle difference is between the following two definitions:

1) For p to point to x, p must contain the address of x.

2) For p to point to x, p must not only contain the address of x, p must
also be of the correct type.

Consider:

#include <iostream>

int main()
{
int a[3];
int *p = &a[0]; // or just 'a'
int (*q)[3] = &a;
std::cout << p << ' ' << q << '\n';
return 0;
}

This prints out the same value twice -- &a[0] and &a have the same
*value*, but different *type*. By definition (1), both p and q point to
a. By definition (2), only q points to a, because p's type dictates that
it points to an int.

One can define "points to" either way (indeed any way one likes), but
definition (2) highlights that there is a difference between the way in
which p and q "point to" a, whereas definition (1) does not. For the
purposes of being precise when there may be ambiguity involved,
definition (2) thus appears preferable in more formal discussion. PMMV
(Paul's mileage may vary).

Unfortunately although your description seems to describe Paul's
misunderstanding perfectly he will still disagree due to the fact that
he is troll (in addition to being clueless).

/Leigh

That hadn't been entirely lost on me Just figured I'd at least
provide some clarity for the benefit of anyone else who might happen to
be reading the thread.

Cheers,
Stu