An array is just a pointer

[Paul]

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

Only pointers of an array type point to an array of said type.
Only pointers of an array type return an array of data when
dereferenced.

Err no
A pointer of type int(*)[10] doesn't point to an array of type
int[10], it
points to an array of type int[10];
I said, "said type". You have changed my statement based on what is
going on in your head.

At least you are starting to use proper terminology, so progress has
been made.

A pointer of type int(*)[10], also the same as int[10]*, points to
an
array of 10 int.

No you are wrong. it points to an array of type int[10].
When it's dereferenced it points to an array of int[10] type.

When a pointer of type int(*)[10] is dereferenced the result is not a
pointer so it doesn't point to anything; the result of the dereference
is a reference of type int[10].


int (*x)[10] = new int[3][10];

If x is dereferenced like so ...x[0] , x is converted to a pointer to
int[10]. This means x is not a pointer to int[10] to begin with.
It's a pointer to int[3][10].

Wrong; x is not converted to a pointer to int[10] as it is *already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

int x[3][5];

Here x is a 3 × 5 array of ints; more precisely, x is an array of three
element objects, each of which is an array of five ints. In the
expression x, which is equivalent to (*((x)+(i))), x is first
converted to a pointer to the initial array of five ints.

It cannot be any clearer than that.

Yes that part of the standard is quite clear; I am not sure why you are
quoting it though as nobody has contradicted it as we are talking about
something different. An array is not a pointer; the Standard's
description of what happens (or an equivalence of what happens) when
subscripting an array does not invalidate this axiom.

It confirms what you said is complete and utter bollocks ref:

Wrong; x is not converted to a pointer to int[10] as it is *already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

</quote>

The C++ standards directly contradict what you think.

 

[James Kanze]

What are you talking about , if its pointing ot the first
element of the array it is also pointing to the array.

Only in the sense that it is also pointing to an unsigned char,
and who knows what all else. The physical pointer is pointing
to some place in memory, which can, as far as the hardware is
concerned, be anything.

In C++, pointers have a type. And an int is not an array, and
if the pointer points to an int, it cannot point to an array,
because an int is not an array.

 

[James Kanze]

In what way have i condracted anything?

If the pointer points to an element of the array, it doesn't
point to the array. A pointer points to exactly one thing, and
only one thing.

[...]

void foo(int p[]){
std::cout<< p << typeid(p).name();
}
int main()
{
int arr[];
foo("Is this an array?" );
}
Is an array passed to foo,

It can't be. The standard explicitly says that arrays can't be
passed as arguments.

Where? Can you show me the quote.

§8.3.5/3: "After determining the type of each parameter, any
parameter of type “array of T” or “function returning T” is
adjusted to be “pointer to T” or “pointer to function returning
T,” respectively."

Since you can't declare a function with a parameter type that is
an array, you can't pass an array as an argument.

You are obviously speaking utter nonsense. I can pass a array
by reference.

You can pass a reference to an array, but you can't pass the
array itself.

SO you can pass a pointer to an array, that is called passing
by reference.

No. Passing by reference is when you pass a reference. But in
C++, passing a reference is still distinct from passing the
object itself.

Still, I'll grant you the pass by reference point: if the
function is declared to take a reference to an array, you can
pass it an array (by reference).

I just did .

No. Since there was no operator<< which takes an array (by
reference or otherwise), the compiler tried all possible
implicit conversions to find a match. You actually passed the
operator<< a pointer, not an array.

Oh yeah , well I seem to be correcting you alot lately.

With erroneous statements.

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

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?

If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.

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))

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.

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

Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.

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

No. C++ doesn't support indexing into an array. It just
doesn't exist.

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

Undefined behavior can result in anything.

No it can point to an array.

Not if the type is int*. It points to an int, and an int is
*not* 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]. ]"

Exactly. The new expression yields a pointer to the initial
element of an array. Not to the array.

 

[Paul]

Only in the sense that it is also pointing to an unsigned char,
and who knows what all else. The physical pointer is pointing
to some place in memory, which can, as far as the hardware is
concerned, be anything.

In C++, pointers have a type. And an int is not an array, and
if the pointer points to an int, it cannot point to an array,
because an int is not an array.

In C++ a pointer to an array has a type of n-1 dim of the array it points
to.
I'd have thought you'd know better but obviously I had a high regard for you
than you deserved.

 

[Paul]

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

Only pointers of an array type point to an array of said type.
Only pointers of an array type return an array of data when
dereferenced.

Err no
A pointer of type int(*)[10] doesn't point to an array of type
int[10], it
points to an array of type int[10];
I said, "said type". You have changed my statement based on what
is
going on in your head.

At least you are starting to use proper terminology, so progress
has
been made.

A pointer of type int(*)[10], also the same as int[10]*, points
to an
array of 10 int.

No you are wrong. it points to an array of type int[10].
When it's dereferenced it points to an array of int[10] type.

When a pointer of type int(*)[10] is dereferenced the result is not
a
pointer so it doesn't point to anything; the result of the
dereference
is a reference of type int[10].


int (*x)[10] = new int[3][10];

If x is dereferenced like so ...x[0] , x is converted to a pointer to
int[10]. This means x is not a pointer to int[10] to begin with.
It's a pointer to int[3][10].

Wrong; x is not converted to a pointer to int[10] as it is *already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

int x[3][5];

Here x is a 3 × 5 array of ints; more precisely, x is an array of three
element objects, each of which is an array of five ints. In the
expression x, which is equivalent to (*((x)+(i))), x is first
converted to a pointer to the initial array of five ints.

It cannot be any clearer than that.

Yes that part of the standard is quite clear; I am not sure why you
are quoting it though as nobody has contradicted it as we are talking
about something different. An array is not a pointer; the Standard's
description of what happens (or an equivalence of what happens) when
subscripting an array does not invalidate this axiom.

It confirms what you said is complete and utter bollocks ref:

Wrong; x is not converted to a pointer to int[10] as it is *already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

</quote>

Nothing in that quote is "utter bollocks"; if x is of type int(*)[10] then
it is already a pointer to int[10]

No it's not, it's converted to a pointer to an array of 10 ints when its
dereferenced, which is of type int*.

and x[0] is a reference to an int[10] array as sizeof(x[0]) will still
confirm.

No it's not. x[0] is equivalent to (*((x)+(0))), x is converted to a pointer
to the initial array of 10 ints, which is of type int*.

I hate having to repeat myself to clueless individuals.
Ditto

I see no contradiction; as I said that quote is correct.

Its uttterly incorrect.

 

[Paul]

In what way have i condracted anything?

-If the pointer points to an element of the array, it doesn't
-point to the array. A pointer points to exactly one thing, and
-only one thing.

Thats where you are so wrong.
A pointer to an array element is exactly a pointer to an array.

Examine the following:
int (*p)[10] = new int[3][10];

Does this pointer point to an array of type int[10] or of type int[3][10]?

I'll tell you , it points to an array of int[3][10], if I dereference it
with:
p[0];
its converted to a pointer that points to an int[10] array(which is an int*
type), which yields an int when dereferenced.
p[0][0];
yields an int , not an array of integers.

A pointer to an array of integers is of type int*. It needs to be so that
when it's dereferenced like so, p[0], it yields and int.

[...]

void foo(int p[]){
std::cout<< p << typeid(p).name();
}
int main()
{
int arr[];
foo("Is this an array?" );
}
Is an array passed to foo,

It can't be. The standard explicitly says that arrays can't be
passed as arguments.

Where? Can you show me the quote.

--§8.3.5/3: "After determining the type of each parameter, any
--parameter of type “array of T” or “function returning T” is
--adjusted to be “pointer to T” or “pointer to function returning
--T,” respectively."

--Since you can't declare a function with a parameter type that is
--an array, you can't pass an array as an argument.


You can pass an array by reference:

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

foo("I am passing this array of chars to a function");

You are obviously speaking utter nonsense. I can pass a array
by reference.

--You can pass a reference to an array, but you can't pass the
--array itself.

What do you mean by pass the array itself, actually pass the memory into a
function? I don't understand this concept.

SO you can pass a pointer to an array, that is called passing
by reference.

--No. Passing by reference is when you pass a reference. But in
--C++, passing a reference is still distinct from passing the
--object itself.

No pass by reference is a term that means to passing without copying. But I
admit this is dubious as it could also mean what you said.
What i do is qualify the term with pass by reference& when I mean what you
said.

--Still, I'll grant you the pass by reference point: if the
--function is declared to take a reference to an array, you can
--pass it an array (by reference).

pass by reference& doesn't pass the actually array anymore than pass by
pointer does. But i'm not sure what you mean by "the actual array", if you
mean the actual memory then that is not possible with any C++ function
parameter.


Let me explain:

C++ function parameters can be passed by value( a copy ) or passed by
reference( no copy). So if you mean copying the whole array onto the stack
you would need to do this:

#include <iostream>

void foo(int a, int b, int c, int d, int e, int f){
int arr[6] ={ a,b,c,d,e,f };
for (int i=0;i<=5;i++ )
{
std::cout <<arr;
}
}
int main()
{
int arr[6] = { 1,2,3,4,5,6};
foo(arr[0], arr[1], arr[2], arr[3], arr[4], arr[5]);
}

Is this what you mean by passing an array to a function?

I just did .

--No. Since there was no operator<< which takes an array (by
--reference or otherwise), the compiler tried all possible
--implicit conversions to find a match. You actually passed the
--operator<< a pointer, not an array.

I have demonstrated different ways to pass an array by both value and by
reference, do you still think an array cannot be passed to a function?

Oh yeah , well I seem to be correcting you alot lately.

--With erroneous statements.

You have proved none of my statements to be erroneous.

 

[Paul]

On 18/03/2011 23:27, Paul wrote:

On 18/03/2011 22:55, Paul wrote:
<snip>

Only pointers of an array type point to an array of said type.
Only pointers of an array type return an array of data when
dereferenced.

Err no
A pointer of type int(*)[10] doesn't point to an array of type
int[10], it
points to an array of type int[10];
I said, "said type". You have changed my statement based on
what is
going on in your head.

At least you are starting to use proper terminology, so progress
has
been made.

A pointer of type int(*)[10], also the same as int[10]*, points
to an
array of 10 int.

No you are wrong. it points to an array of type int[10].
When it's dereferenced it points to an array of int[10] type.

When a pointer of type int(*)[10] is dereferenced the result is
not a
pointer so it doesn't point to anything; the result of the
dereference
is a reference of type int[10].


int (*x)[10] = new int[3][10];

If x is dereferenced like so ...x[0] , x is converted to a
pointer to
int[10]. This means x is not a pointer to int[10] to begin with.
It's a pointer to int[3][10].

Wrong; x is not converted to a pointer to int[10] as it is
*already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

int x[3][5];

Here x is a 3 × 5 array of ints; more precisely, x is an array of
three
element objects, each of which is an array of five ints. In the
expression x, which is equivalent to (*((x)+(i))), x is first
converted to a pointer to the initial array of five ints.

It cannot be any clearer than that.

Yes that part of the standard is quite clear; I am not sure why you
are quoting it though as nobody has contradicted it as we are talking
about something different. An array is not a pointer; the Standard's
description of what happens (or an equivalence of what happens) when
subscripting an array does not invalidate this axiom.


It confirms what you said is complete and utter bollocks ref:
<quote ref="Leigh">
Wrong; x is not converted to a pointer to int[10] as it is *already*
a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.
</quote>

Nothing in that quote is "utter bollocks"; if x is of type int(*)[10]
then it is already a pointer to int[10]

No it's not, it's converted to a pointer to an array of 10 ints when its
dereferenced, which is of type int*.

Yes it is; if x is of type int(*)[10] then x is a pointer; more
specifically it is a pointer to an array of 10 ints. You need to re-learn
what you think you know about pointers.

and x[0] is a reference to an int[10] array as sizeof(x[0]) will still
confirm.

No it's not. x[0] is equivalent to (*((x)+(0))), x is converted to a
pointer to the initial array of 10 ints, which is of type int*.

Yes it is; x is already a pointer (no conversion required) and the result
of x[0] or (*((x)+(0))) is a reference of type int[10] rather than a
pointer; all you have to do to confirm this is use the sizeof operator;
heck I will do it for you:

dude the standard clearly states its converted to a pointer that points to
int[10].
a reference is not a pointer.

int main()
{
int a[10];
int (*x)[10] = &a;
std::cout << sizeof(int[10]) << std::endl;
std::cout << sizeof(x[0]) << std::endl;
std::cout << sizeof((*((x)+(0)))) << std::endl;
std::cout << sizeof(int*) << std::endl;
}

outputs:

40
40
40
4

Now STFU; you have been proven wrong so many times it is no longer funny
(just tedious).

Eh.
What is that nonsnese supposed to mean?

See above.

One again you have been proven wrong, now you are just babbling a complete
load of nonsense about references.

 

[Paul]

"James Kanze" <[email protected]> wrote in message

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?

If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.

^^idiot^^.
You are unreasonable.

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))

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.

Please provide relevant paragraph.

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

Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.

How does it have undefined behaviour?
Please provide the relevant paragraph of the C++ standards.

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

No. C++ doesn't support indexing into an array. It just
doesn't exist. This is utter nonsense.

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

Undefined behavior can result in anything. What is undefined behaviour?

No it can point to an array.

Not if the type is int*. It points to an int, and an int is
*not* an array.

No it doesn't a pointer to an array of int's is of type int*.

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

Exactly. The new expression yields a pointer to the initial
element of an array. Not to the array.

If it points to the intial element of an array, then it points to the array.

 

[SG]

If the result of x[0] was a pointer then the output of
sizeof(x[0]) would be 4 not 40 above.

You could have the same fight with a hard core C programmer who thinks
"the name of an array is a pointer expression" because that's pretty
much what the ISO C standard says with the exception "unless it's used
as operand for sizeof or the address operator". The issue is that the
implicit conversion T[N] --> T* is "invisible". And by that I mean the
expression that *excludes* this conversion looks the same as the
expression that *includes* this conversion judging by the sequence of
characters the expressions are made of. So, when one guy says the type
of such and such subexpression is T* and the other one says that it's
T[N], obviously the first guy included the implicit conversion, while
the other one did not. Since I don't like rules with many exceptions
(in C++ we would have at least 4 exceptions: sizeof, &, reference
binding, decltype) I like to consider a possible implicit conversion
as not being part of a subexpression (that refers to an array) but as
something that is conditionally applied "in-between".

SG

 

[Paul]

Only pointers of an array type point to an array of said
type.
Only pointers of an array type return an array of data when
dereferenced.

Err no
A pointer of type int(*)[10] doesn't point to an array of
type
int[10], it
points to an array of type int[10];
I said, "said type". You have changed my statement based on
what is
going on in your head.

At least you are starting to use proper terminology, so
progress
has
been made.

A pointer of type int(*)[10], also the same as int[10]*,
points
to an
array of 10 int.

No you are wrong. it points to an array of type int[10].
When it's dereferenced it points to an array of int[10] type.

When a pointer of type int(*)[10] is dereferenced the result is
not a
pointer so it doesn't point to anything; the result of the
dereference
is a reference of type int[10].


int (*x)[10] = new int[3][10];

If x is dereferenced like so ...x[0] , x is converted to a
pointer to
int[10]. This means x is not a pointer to int[10] to begin with.
It's a pointer to int[3][10].

Wrong; x is not converted to a pointer to int[10] as it is
*already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.

int x[3][5];

Here x is a 3 × 5 array of ints; more precisely, x is an array of
three
element objects, each of which is an array of five ints. In the
expression x, which is equivalent to (*((x)+(i))), x is first
converted to a pointer to the initial array of five ints.

It cannot be any clearer than that.

Yes that part of the standard is quite clear; I am not sure why you
are quoting it though as nobody has contradicted it as we are
talking
about something different. An array is not a pointer; the Standard's
description of what happens (or an equivalence of what happens) when
subscripting an array does not invalidate this axiom.


It confirms what you said is complete and utter bollocks ref:
<quote ref="Leigh">
Wrong; x is not converted to a pointer to int[10] as it is
*already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.
</quote>

Nothing in that quote is "utter bollocks"; if x is of type int(*)[10]
then it is already a pointer to int[10]
No it's not, it's converted to a pointer to an array of 10 ints when
its
dereferenced, which is of type int*.

Yes it is; if x is of type int(*)[10] then x is a pointer; more
specifically it is a pointer to an array of 10 ints. You need to
re-learn what you think you know about pointers.


and x[0] is a reference to an int[10] array as sizeof(x[0]) will still
confirm.
No it's not. x[0] is equivalent to (*((x)+(0))), x is converted to a
pointer to the initial array of 10 ints, which is of type int*.

Yes it is; x is already a pointer (no conversion required) and the
result of x[0] or (*((x)+(0))) is a reference of type int[10] rather
than a pointer; all you have to do to confirm this is use the sizeof
operator; heck I will do it for you:

dude the standard clearly states its converted to a pointer that points
to int[10].
a reference is not a pointer.

Wrong; see below for why.

int main()
{
int a[10];
int (*x)[10] = &a;
std::cout << sizeof(int[10]) << std::endl;
std::cout << sizeof(x[0]) << std::endl;
std::cout << sizeof((*((x)+(0)))) << std::endl;
std::cout << sizeof(int*) << std::endl;
}

outputs:

40
40
40
4

Now STFU; you have been proven wrong so many times it is no longer
funny (just tedious).

Eh.
What is that nonsnese supposed to mean?

If the result of x[0] was a pointer then the output of sizeof(x[0]) would
be 4 not 40 above.

See below:

int (*p)[5] = new int[3][5];
std::cout<<"sizeof p[0]:\t"<< sizeof(p[0]);
std::cout<<std::endl<<"sizeof *p:\t"<<sizeof(*p);

The result of either p[0] or (*p), which is identical, is the pointed-to
(n-1)dimensional array.
The pointed-to array is a 2dim array(an int[3][5] array), after
dereferencing it becomes a 1dim array(an int[5] array).

Ref C++ standards:
"If the * operator, either explicitly or implicitly as a result of
subscripting, is applied to
this pointer, the result is the pointedto (n - 1 )dimensional array, which
itself is immediately converted
into a pointer."

int(*)[5] is a pointer-to a 2D array. It's a pointer-to-type int[5].

I have been proven wrong about what exactly?

Levels of dereference with pointers to arrays.

Where is this proof?

Above.

 

[James Kanze]

[...]
A pointer to an array element is exactly a pointer to an array.

I give up. I don't think we can go any further until you learn
basic English.

 

[James Kanze]

news:9ac6022f-2075-47f8-8fcb-0261dcc7df74@v31g2000vbs.googlegroups.com...

[...]

If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.

^^idiot^^.
You are unreasonable.

No. I'm basing my arguments on the C and the C++ standards.
In which operator [] does not take an array argument.

[...]

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.

Please provide relevant paragraph.

§5.7/5. The last sentence says "If both the pointer operand and
the result point to elements of the same array object, or one
past the last element of the array object, the evaluation shall
not produce an overflow; otherwise, the behavior is undefined."

The array object in question is, of course, that constructed by
the new expression.

Is this an array or is it just a pointer?
Again, is what an array or just a pointer.
Again, the entity I indexed with the expression arr2[-1], wtf
do you think?

Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.

How does it have undefined behaviour?
Please provide the relevant paragraph of the C++ standards.

See above. You've constructed an array with 11 elements, and
you've taken a pointer to the first element, and subtracted one.
The results neither point to an element in the array, or one
past the end, so you have undefined behavior.

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?

No. C++ doesn't support indexing into an array. It just
doesn't exist.

This is utter nonsense.

Where in the C++ standard is an operator defined that indexes
into an array.

[...]

No it doesn't a pointer to an array of int's is of type int*.

A pointer to an array of int's is of type int (*)[]. Something
completely different.

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 typeof
new int[10] is int (*)[10]. ]"

Exactly. The new expression yields a pointer to the initial
element of an array. Not to the array.

If it points to the intial element of an array, then it points
to the array.

Not according to any normal use of English. Nor to the way the
C++ standard uses English (which isn't always "normal").

 

[Paul]

[...]
A pointer to an array element is exactly a pointer to an array.

I give up. I don't think we can go any further until you learn
basic English.

--

You can't point to a banana in a bunch without also pointing at the bunch of
bananas.

I think you are the one who needs to learn basic English, you're just as bad
as Leigh with your nonsense.

 

[SG]

You can't point to a banana in a bunch without also pointing at the
bunch of bananas.

This analogy is broken. Your finger has no type in the sense that this
type would restrict what your finger can point to. A pointer variable
in C++ has a type. This type (T*) tells you what this pointer may
point to (something of type T). Now, T can be an array type (for
example, T=int[99]) in which case we can say that the pointer points
to an array. If T=int, this pointer only points to a single int. This
int might be surrounded by other int objects of the same int-array,
sure, but saying that the pointer in question "also points to the
array" is _imprecise_ at best.

you're just as bad as Leigh with your nonsense.

There is more than one explanation for why the things people write
don't make sense to you. At least three come to my mind.

SG

 

[Paul]

news:9ac6022f-2075-47f8-8fcb-0261dcc7df74@v31g2000vbs.googlegroups.com...

[...]

If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.

^^idiot^^.
You are unreasonable.

--No. I'm basing my arguments on the C and the C++ standards.
--In which operator [] does not take an array argument.


I think this further justifies my reference to your posting as that of an
idiot.

Or perhaps I am being rude and you trully don't understand English.


[...]

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.

Please provide relevant paragraph.

--§5.7/5. The last sentence says "If both the pointer operand and
--the result point to elements of the same array object, or one
--past the last element of the array object, the evaluation shall
--not produce an overflow; otherwise, the behavior is undefined."

--The array object in question is, of course, that constructed by
--the new expression.

That means its valid and perfectly defined to do the following:
int* arr = new int[16];
arr++;
arr[-1] = -1;


And also..
From 1.7 The C++ object model:
"The term object type refers to the type with which the object is created"

The above array and also the following are array objects of int type:
int arr[16]={0};

int* p_arr = arr;
p_arr points to an individual element of the array, so it must also point to
the array.
You cannot point to a single banana in a bunch without pointing at the bunch
of bananas.

p_arr = &arr /*This is wrong*/
An array is not any one single address, an array is a whole *drumroll* array
of addresses.

Is this an array or is it just a pointer?
Again, is what an array or just a pointer.
Again, the entity I indexed with the expression arr2[-1], wtf
do you think?

Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.

How does it have undefined behaviour?
Please provide the relevant paragraph of the C++ standards.

--See above. You've constructed an array with 11 elements, and
--you've taken a pointer to the first element, and subtracted one.
--The results neither point to an element in the array, or one
--past the end, so you have undefined behavior.

No I created an array of 12 elements.
I will repost the code to give you a chance because, in this second example
there *was* some doubt and you may have actually had a valid argument this
time.

int* arr1 = new int[12]; /*Create an array of 12 int*/
arr1[0] = 33;
int* arr2 = new(++arr1) int[11]; /*Create an sub-array within original*/
std::cout<< arr2[-1]; /*Access the original array using the sub-arrays
pointer*/

If I add the following code pre-accessing the array it's unbreakable:
if(arr1==arr2)

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?

No. C++ doesn't support indexing into an array. It just
doesn't exist.

This is utter nonsense.

--Where in the C++ standard is an operator defined that indexes
--into an array.

Indexing:
a. Mathematics A number or symbol, often written as a subscript or
superscript to a mathematical expression, that indicates an operation to be
performed, an ordering relation, or a use of the associated expression.

The subscript operator indexes an array , learn to live with this it won't
be going away.


<snip>

 

[Paul]

This analogy is broken. Your finger has no type in the sense that this
type would restrict what your finger can point to.

No it's almost the perfect analogy for an array object of subobjects.

A pointer variable
in C++ has a type. This type (T*) tells you what this pointer may
point to (something of type T).

MAY point to? What kind of programmer are you if you just guess at what
things point to?

Now, T can be an array type (for
example, T=int[99]) in which case we can say that the pointer points
to an array. If T=int, this pointer only points to a single int.

It ONLY points to a single int now? You've changed your opinion since 3
lines above.

This
int might be surrounded by other int objects of the same int-array,
sure, but saying that the pointer in question "also points to the
array" is _imprecise_ at best.

The only thing imprecise is your completely incorrect, back-to-front way of
looking at things.

There is more than one explanation for why the things people write
don't make sense to you. At least three come to my mind.

There is more than one explanation for things but in your case , your
explanation is a mess, flawed and completely incorrect. I'm sorry to say.

And as not to appear rude I will present and explanation:
Animal* p_Cat = new Cat;
This pointer points to a Cat object, the pointer is of type Animal*. It
points do both a Cat object and the Animal subobject of Cat.

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

[...]

If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.

^^idiot^^.
You are unreasonable.

--No. I'm basing my arguments on the C and the C++ standards.
--In which operator [] does not take an array argument.

I think this further justifies my reference to your posting as
that of an idiot.

The C++ standard explicitly says that one of the operands to []
must be a pointer, and the other must have an integral type. No
array allowed.

Or perhaps I am being rude and you trully don't understand English.

I'd suggest that you read the standard.

[...]

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.

Please provide relevant paragraph.

-- 5.7/5. The last sentence says "If both the pointer operand and
--the result point to elements of the same array object, or one
--past the last element of the array object, the evaluation shall
--not produce an overflow; otherwise, the behavior is undefined."

--The array object in question is, of course, that constructed by
--the new expression.

That means its valid and perfectly defined to do the following:
int* arr = new int[16];
arr++;
arr[-1] = -1;

Certainly. But that's not what you did. What you did was:

int* array = new int[16];
int* arr2 = new (array + 1) int[15];

That second line constructs a new array, of 15 elements, and
returns a pointer to the first element. You cannot subtract
anything from arr2 until you've incremented.

And also..
From 1.7 The C++ object model:
"The term object type refers to the type with which the object is created"

The above array and also the following are array objects of int type:
int arr[16]={0};

int* p_arr = arr;
p_arr points to an individual element of the array, so it must
also point to the array.

p_arr points to an individual element of the array (the first),
so it cannot point to the array. You can't have it both ways.

You cannot point to a single banana in a bunch without
pointing at the bunch of bananas.

Sure you can. Not that that's relevant here. Pointers in C++
can't point to actual bananas.

But I think I see what's confusing you, The actual, hardware
pointer certainly points to the first element, the array, and
array of bytes, and probably just about anything else you want
to say it points to. But we're not talking about the hardware
pointer here. We're talking about a pointer in C++. And in
C++, pointers have a type, and can only point to that type.

p_arr = &arr /*This is wrong*/
An array is not any one single address, an array is a whole
*drumroll* array of addresses.

An array isn't an address at all. It's a sequence of a given
type.

Is this an array or is it just a pointer?
Again, is what an array or just a pointer.
Again, the entity I indexed with the expression arr2[-1], wtf
do you think?
Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.

How does it have undefined behaviour?
Please provide the relevant paragraph of the C++ standards.

--See above. You've constructed an array with 11 elements, and
--you've taken a pointer to the first element, and subtracted one.
--The results neither point to an element in the array, or one
--past the end, so you have undefined behavior.

No I created an array of 12 elements.
I will repost the code to give you a chance because, in this second example
there *was* some doubt and you may have actually had a valid argument this
time.

int* arr1 = new int[12]; /*Create an array of 12 int*/
arr1[0] = 33;
int* arr2 = new(++arr1) int[11]; /*Create an sub-array within original*/

You see. You even say so: new int[11] creates a new array of 11
ints, and returns a pointer to the first element of that array.
Not a pointer to arr1.

std::cout<< arr2[-1]; /*Access the original array using the sub-arrays
pointer*/

arr2 doesn't point into the first array; it points into the
array you created with the new expression which you used to
initialized arr2.

If I add the following code pre-accessing the array it's unbreakable:
if(arr1==arr2)

So.

You do have an interesting point, although you fail to mention
it. The array originally pointed to by arr1 is been replaced by
a new array; so accessing it is formally undefined behavior. I
don't know if this was actually the intention of the committee,
but taken literally, that's what the standard says. The
lifetime of an object ceases when another object is created in
the memory it occupies.

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?
No. C++ doesn't support indexing into an array. It just
doesn't exist.

This is utter nonsense.

--Where in the C++ standard is an operator defined that indexes
--into an array.

Indexing:
a. Mathematics A number or symbol, often written as a subscript or
superscript to a mathematical expression, that indicates an operation to be
performed, an ordering relation, or a use of the associated expression.

That's the definition of indexing into an array. So where is an
operator that does this defined in the C++ standard?

The subscript operator indexes an array , learn to live with this it won't
be going away.

The subscript operator does NOT index in C++. It does pointer
arithmetic, then dereferences the results.

 

[Paul]

"James Kanze" <[email protected]> wrote in message

[...]
If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.
^^idiot^^.
You are unreasonable.

--No. I'm basing my arguments on the C and the C++ standards.
--In which operator [] does not take an array argument.

I think this further justifies my reference to your posting as
that of an idiot.

The C++ standard explicitly says that one of the operands to []
must be a pointer, and the other must have an integral type. No
array allowed.

Or perhaps I am being rude and you trully don't understand English.

I'd suggest that you read the standard.

I suggest you stop speaking such utter bool.

[...]

Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.
Please provide relevant paragraph.

-- 5.7/5. The last sentence says "If both the pointer operand and
--the result point to elements of the same array object, or one
--past the last element of the array object, the evaluation shall
--not produce an overflow; otherwise, the behavior is undefined."

--The array object in question is, of course, that constructed by
--the new expression.

That means its valid and perfectly defined to do the following:
int* arr = new int[16];
arr++;
arr[-1] = -1;

Certainly. But that's not what you did. What you did was:

I clearly presented 2 examples.

int* array = new int[16];
int* arr2 = new (array + 1) int[15];

That second line constructs a new array, of 15 elements, and
returns a pointer to the first element. You cannot subtract
anything from arr2 until you've incremented.

And also..
From 1.7 The C++ object model:
"The term object type refers to the type with which the object is
created"

The above array and also the following are array objects of int type:
int arr[16]={0};

int* p_arr = arr;
p_arr points to an individual element of the array, so it must
also point to the array.

p_arr points to an individual element of the array (the first),
so it cannot point to the array. You can't have it both ways.

You cannot point to a single banana in a bunch without
pointing at the bunch of bananas.

Sure you can.

Please explain then.. I await some completely nonsensical philosophical
bullshit.

Not that that's relevant here. Pointers in C++
can't point to actual bananas.

Yes they can See I can be unreasonable too, if I want but I'm not like
that and obviously joking.

But I think I see what's confusing you,

You are the one who is confused not me.

The actual, hardware
pointer certainly points to the first element, the array, and
array of bytes, and probably just about anything else you want
to say it points to. But we're not talking about the hardware
pointer here.

YOu seem to be talking about the hardware pointer, not me I never mentioned
such a thing , whatever it is.

We're talking about a pointer in C++. And in
C++, pointers have a type, and can only point to that type.

No they point to objects in memory. That's why pointer values are memory
addresses.

An array isn't an address at all. It's a sequence of a given
type.

It's an arrangement of memory elements in one or more planes.

Is this an array or is it just a pointer?
Again, is what an array or just a pointer.
Again, the entity I indexed with the expression arr2[-1], wtf
do you think?
Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.
How does it have undefined behaviour?
Please provide the relevant paragraph of the C++ standards.

--See above. You've constructed an array with 11 elements, and
--you've taken a pointer to the first element, and subtracted one.
--The results neither point to an element in the array, or one
--past the end, so you have undefined behavior.

No I created an array of 12 elements.
I will repost the code to give you a chance because, in this second
example
there *was* some doubt and you may have actually had a valid argument
this
time.

int* arr1 = new int[12]; /*Create an array of 12 int*/
arr1[0] = 33;
int* arr2 = new(++arr1) int[11]; /*Create an sub-array within original*/

You see. You even say so: new int[11] creates a new array of 11
ints, and returns a pointer to the first element of that array.
Not a pointer to arr1.

No I said I created an array of 12 ints, then I create and sub-array within
it, which returns a pointer with a value identical to that of arr1.

std::cout<< arr2[-1]; /*Access the original array using the sub-arrays
pointer*/

arr2 doesn't point into the first array; it points into the
array you created with the new expression which you used to
initialized arr2.

arr2 and arr1 both point to the same memory location.

So.

You do have an interesting point, although you fail to mention
it. The array originally pointed to by arr1 is been replaced by
a new array; so accessing it is formally undefined behavior. I
don't know if this was actually the intention of the committee,
but taken literally, that's what the standard says. The
lifetime of an object ceases when another object is created in
the memory it occupies.

But the subobjects , which are in themselves little complete objects, that
extend beyond the overwritten memory survive the overwrite operation.
So they were spared certain death by the ending of their lifetime.

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?
No. C++ doesn't support indexing into an array. It just
doesn't exist.
This is utter nonsense.

--Where in the C++ standard is an operator defined that indexes
--into an array.

Indexing:
a. Mathematics A number or symbol, often written as a subscript or
superscript to a mathematical expression, that indicates an operation to
be
performed, an ordering relation, or a use of the associated expression.

That's the definition of indexing into an array. So where is an
operator that does this defined in the C++ standard?

I'm not too bothered about where definitions are in the standard , I know
its simply ridiculous to suggest you cannot index an array in C++ and I
don't intend wasting my time looking for definitons to present to you for
unreasonable responses.

The subscript operator does NOT index in C++. It does pointer
arithmetic, then dereferences the results.

Well it does index then if you have any clue what array indexing is.

 

[SG]

MAY point to?

Yes. Pointers can be "null" in which case they don't point to
anything.

You've changed your opinion since 3 lines above.

I did not change my opinion + You think I did = You misunderstood.

The only thing imprecise is your completely incorrect,
back-to-front way of looking at things.

You are alone with this view point.

SG