Problem with array objects

P

Paul

A. Bolmarcich said:
[snip]

If you take pa1i and consider it a pointer to a 1d array, this fails
because *pa1i does not produce the pointed to (n-1) dimensional
array,
which
would be a single int( a zero dim array).

Nothing fails here by considering pa1i to be a pointer to a
1-dimensional array, which is what it is. Evaluating *pa1i results
in a 1-dimensional array,

One final thing , that does fail because it doesn'tt comply with the
rules.
A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim
array.
(2-1) != (1-1)

I never claimed that a pointed to (n-1) dim array was the same for a
1dim and 2dim array. With the omitted part of a sentence restored,
what I wrote was

Nothing fails here by considering pa1i to be a pointer to a
1-dimensional array, which is what it is. Evaluating *pa1i results
in a 1-dimensional array, which is implicitly converted to a pointer
to the first element of that array.

pa1i was declared as a pointer to a 2d array with:
int a2i[3][5], (*pa1i)[5] = a2i;

In that declaration pa1i is declared as a pointer to a 1-dimensional
array. Here is an example from section 8.1 (Type Names) of the C++
standard.

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

name respectively the types "int," "pointer to int," "array of 3
pointers to int," "pointer to array of 3 int," "function of (no
parameters) returning pointer to int," and "pointer to a function
of (double) returning int.
Thats the pointer-types, not what it points to.
If you interpret this as saying pa1i does not point to a 2d array then you
have some serious intellectual problems.

According to the C++ standard, "int (*p3i)[3]" declares a "pointer
to an array of 3 int". That array has one dimension.
No it doesn't the standard clearly says that is a TYPE. The standard does
not define that it points to a 1d array. The standard actually implies that
type points to a 2d array, in the section about pointers to arrays..
Dereferencing pa1i returns a 1d array, which is fine if n==2 because
(n-1)
== 1
If you consider it to be 1d array then n==1, and (n-1) !=1.

std::cout << typeid(*pa1i).name ;
outputs int[5]. There is no implicit conversion to pointer unless it's
further dereferenced i.e: pali[0][0].

There is no implicit conversion in a typeid expression. According
to paragraph 3 of section 5.2.8 (Type identification) of the C++
standard:

When typeid is applied to an expression other than an lvalue of
a polymorphic class type, the result refers to a type_info object
representing the static type of the expression. Lvalue-to-rvalue
(4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
conversions are not applied to the expression. If the type of
the expression is a class type, the class shall be
completely-defined. The expression is not evaluated.

The output "int[5]" demonstrates that pali is a pointer to a 1-dimensional
array. In a context where the expression *pa1i is evaluated, the
resulting
1-dimensional array undergoes array-to-pointer conversion, resulting in a
pointer to int.
The output demonstrates its an array , not a pointer.
The type int[5] is not a pointer. As I said this is not implicitly converted
to a pointer until its further dereferenced. And when it is converted to a
pointer it will be pointer-type: int*, not int (*)[5].
What you omitted from what I wrote was: "which is implicitly converted to
a
pointer to the first element of that array". The initial value in the
declaration of pali is a pointer to a 1-dimensional array.
It is initialised to point to a 2d array, with:
int a2i[3][5], (*pa1i)[5] = a2i;

a2i is a 2d array , not a 1d array.
An array is defined at allocation, not by a pointer that points to it.
 
P

Peter Remmers

Am 07.04.2011 00:51, schrieb Paul:
An array is defined at allocation, not by a pointer that points to it.

Actually, this is the core point of your view, not that "int* can point
to an int or an array" - that's just what follows.
You do know about pointer types (at least by now), that's not the
problem. It's just that many of those who still argue with you fail to
see that they're arguing about the wrong thing. They are trying to teach
you something that you already know.

But some have already tried to tell you that "points to" and "is a
pointer to" are not the same, and they also failed. And that's just
because you're a stone deaf:

http://www.politicsforum.org/images/flame_warriors/flame_77.php

Peter
 
P

Paul

A. Bolmarcich said:
pa1i was declared as a pointer to a 2d array with:
int a2i[3][5], (*pa1i)[5] = a2i;

In that declaration pa1i is declared as a pointer to a 1-dimensional
array. Here is an example from section 8.1 (Type Names) of the C++
standard.

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

name respectively the types "int," "pointer to int," "array of 3
pointers to int," "pointer to array of 3 int," "function of (no
parameters) returning pointer to int," and "pointer to a function
of (double) returning int.
Thats the pointer-types, not what it points to.
If you interpret this as saying pa1i does not point to a 2d array then
you
have some serious intellectual problems.

In C++ what a pointer points to depends on the pointer type. Here
is paragraph 1 of section 5.3.1 of the C++ standard:

No, a pointer type doesn't define what is pointed to.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is created.
Some
objects are polymorphic".

The pointer type of a pointer that points to an object in C++ can be a void*
or another type of pointer that is not the same type as the object. You are
misinterpreting the C++ standards.
The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer
to a function type and the result is an lvalue referring to the
object or function to which the expression points. If the type of
the expression is pointer to T, the type of the result is T.
[Note: a pointer to an incomplete type (other than cv void ) can
be dereferenced. The lvalue thus obtained can be used in limited
ways (to initialize a reference, for example); this lvalue must
not be converted to an rvalue, see 4.1.]
This is a paragraph that explains the unary operator *.
It explains how dereferencing works, not what a pointer can or cannot point
to.
I don't have any serious intellectual problems. I am using the term
"points to" with the meaning it has in C++. The meaning of the term
may be different in other contexts, but using another meaning when
discussing C++ may lead to errors.
"Points to" is a term that quite clearly needs no definition in the C++
standard.

The C++ standard state the following;
4.10 Pointer conversions:
"An rvalue of type "pointer to cv T," where T is an object type, can be
converted to an rvalue of type
"pointer to cv void." The result of converting a "pointer to cv T" to a
"pointer to cv void" points to the
start of the storage location where the object of type T resides, as if the
object is a most derived object (1.7)
of type T (that is, not a base class subobject)."

As you can see with a pointer to an object, the pointer actually points to
the start of the objects storage location. So do you think a pointer to an
object doesn't actually point to an object?
According to the C++ standard, "int (*p3i)[3]" declares a "pointer
to an array of 3 int".
Its TYPE is pointer to array. What it points to can be null, or almost
anything.
You are obviously confusing its type with what it points to.


That array has one dimension.

See the above quote from section 5.3.1 of the C++ standard about the
unary * operator, which contains: "If the type of the expression is
a pointer to T, the type of the result is T." A pointer to a 1d
array points to a 1d array. If a pointer to a 1d array could point
to a 2d array, the statement
The above is describing the result of dereferencing a pointer of type T.
This does not define what a pointer points to , a pointer can be null and
point to nothing.

int a2i[3][5], (*pa1i)[5] = &a2i;

would be allowed, but it isn't.

Exactly where (section and paragraph) does the standard state that a
pointer to a 1d array can point to a 2d array, as opposed to can point
to a 1d element of a 2d array?
This is another example of your bad coding, you dont take the address of an
array to get a pointer to it.
Dereferencing pa1i returns a 1d array, which is fine if n==2 because
(n-1)
== 1
If you consider it to be 1d array then n==1, and (n-1) !=1.

std::cout << typeid(*pa1i).name ;
outputs int[5]. There is no implicit conversion to pointer unless it's
further dereferenced i.e: pali[0][0].

There is no implicit conversion in a typeid expression. According
to paragraph 3 of section 5.2.8 (Type identification) of the C++
standard:

When typeid is applied to an expression other than an lvalue of
a polymorphic class type, the result refers to a type_info object
representing the static type of the expression. Lvalue-to-rvalue
(4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
conversions are not applied to the expression. If the type of
the expression is a class type, the class shall be
completely-defined. The expression is not evaluated.

The output "int[5]" demonstrates that pali is a pointer to a
1-dimensional
array. In a context where the expression *pa1i is evaluated, the
resulting
1-dimensional array undergoes array-to-pointer conversion, resulting in
a
pointer to int.
The output demonstrates its an array , not a pointer.
The type int[5] is not a pointer. As I said this is not implicitly
converted
to a pointer until its further dereferenced. And when it is converted to
a
pointer it will be pointer-type: int*, not int (*)[5].

That's right, *pai1i is an array.
So why did you say it was a pointer? Its not a pointer its an array.
The value of "typeid(pa1i).name()"
would indicate that pa1i is a pointer to int[5] (the value
returned by type_info::name() is implementation defined).
No its an array , it not a fucking pointer at all it's an array.
The
type int[5] is not a pointer type. However, when used in a context
where array-to-pointer conversion is applied, a value of type int[5]
is implicitly converted to a pointer to int.
Your last 3 statements said it's a poiinter now you say its not a pointer,
you can't accept that *pa1i returns an array because it proves the standards
confirms it is a pointer to a a 2d array.

[snip]
It is initialised to point to a 2d array, with:
int a2i[3][5], (*pa1i)[5] = a2i;

a2i is a 2d array , not a 1d array.
An array is defined at allocation, not by a pointer that points to it.

Although a2i is a 2d array, when used in the initialization
expression array-to-pointer conversion is applied to it, and the
result is a pointer to the 1d array that is the first element of a2i.
The variable pa1i (a pointer to a 1d array) is initialized to that
pointer to a 1d array result.
The pointed to array is a 2d array, not a 1d array. The pointer type is
pointer to int[5], which does not point to an element, it points to a 2d
array. The reason its type is pointer to 1d array is because of the rules
of the C++ language, the standards state:
When dereferenced a pointer ot an array returns the pointed to (n-1)
dimensional array.
 
P

Paul

From TCPPPL 5.1 Pointers
"For a type T, T* is the type "pointer to T."

int* p = 0;
The pointer p is a pointer-to-int type, it doesn't point to an int.
Oviously, being the idiot that you are, you incorrectly think the
pointer-type defines what is pointed to.
 
P

Paul

cg_chas said:
and presenting a NULL pointer example is supposed to some how refute the
response to previous examples that you snipped?

You have the mind of a child :)

And you have the mind of an idiot :)
The meaning of "For a type T, T* is the type "pointer to T"" is abundantly
clear.

Yes it is quite clear its a pointer type.

<snip unread bullshit>
 
P

Paul

A. Bolmarcich said:
A. Bolmarcich said:
news:[email protected]... [snip]
In C++ what a pointer points to depends on the pointer type. Here
is paragraph 1 of section 5.3.1 of the C++ standard:

No, a pointer type doesn't define what is pointed to.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is
created.
Some
objects are polymorphic".

Although some objects are polymorphic, this discussion has been
about arrays. Arrays are not polymorphic; an array type does not
inherit from another type. The element type of an array may be
polymorphic, but an array is not.
The quote wasn't posted because it mentioned polymorphic types, it was
posted becuase it says:
"The term object type refers to the type with which the object is created."

An objects' type is defined when its created, it is not defined by some
pointer that points to it.
You said :
"In C++ what a pointer points to depends on the pointer type."
This is complete nonsense because a pointed to object is not defined by a
type of pointer, pointing to it.


I'm not misinterpreting the C++ standard. What a pointer may validly
point to is a detail not previously covered in these posts. These
posts are long enough without adding more details. However, since it
appears you want to discuss these details, I'll oblige.

Attempts to access what is pointed may be undefined depending on
whether the pointer type (the static type) and the object type
(the dymanic type) is a valid combination. When T is a
non-polymorphic type, dereferencing a pointer to T attempts to
access an object of type T. When T is a polymorphic type,
dereferencing a pointer to type T attempts to access an object of
type T except when a virtual function is called on the object.

A void* may validly point to any object, but a void* cannot be used to
access what it points to.
Again you said :
"In C++ what a pointer points to depends on the pointer type."
This is completely wrong , a pointer can point to almost anything.

The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer
to a function type and the result is an lvalue referring to the
object or function to which the expression points. If the type of
the expression is pointer to T, the type of the result is T.
[Note: a pointer to an incomplete type (other than cv void ) can
be dereferenced. The lvalue thus obtained can be used in limited
ways (to initialize a reference, for example); this lvalue must
not be converted to an rvalue, see 4.1.]
This is a paragraph that explains the unary operator *.
It explains how dereferencing works, not what a pointer can or cannot
point
to.

According to the standard: "If the type of the expression is a pointer
to T, the type of the result is T." The result of dereferencing a
valid pointer is what the pointer points to.
I know what dereferencing a pointer does, I also know what a pointer can
point to.
You have repeatedly said that, what a pointer points to depends on the
pointer type,which is comletely incorrect.
No, I don't think that; a pointer to an object points to an object.
In C++, pointers have a type in addition to a storage location value.
The result of dereferencing a pointer is what the pointer points to.
The "most derived object" wording applies to an object with a polymorphic
type; an array is not polymorphic.
The pointer type does not define the pointed to object.
According to the C++ standard, "int (*p3i)[3]" declares a "pointer
to an array of 3 int".
Its TYPE is pointer to array. What it points to can be null, or almost
anything.
You are obviously confusing its type with what it points to.

"int (*p3i)[3]" declares pointer to an array of 3 int.
No it declares a pointer of type poiner to array. It doesn't point to
anything valid until its been initialised.
Dereferencing
that pointer results in an array of 3 int.
Dereferencing it results in UB.
The type that was used
when the object allocated does not matter except in a a call to a
virtual function. Dereferencing a pointer that is not pointing to an
object of the right type is undefined behavior.

Of course the allocated object type matters. It would be extremely
incompetent to manipulate memory without knowing what type of data was
represented there.
The allocated object defines the type of object, not some pointer that
points to the memory.

Dereferencing the null pointer is undefined behaviour. The result of
dereferencing a valid pointer to T is a value of type T.
A null pointer is a valid object and well defined in the C++ standards.
int a2i[3][5], (*pa1i)[5] = &a2i;

would be allowed, but it isn't.

Exactly where (section and paragraph) does the standard state that a
pointer to a 1d array can point to a 2d array, as opposed to can point
to a 1d element of a 2d array?
This is another example of your bad coding, you dont take the address of
an
array to get a pointer to it.

The result of the unary & operator is a pointer to its operand. Taking
the address of an array is how you get a pointer to the array. Look at
the return value of typeid(&a2i).name().
No arrays are implicitly converted to pointers, taking the address of an
array creates an unneccessary extra level of indirection
You have not answered the question: Exactly where (section and
paragraph) does the standard state that a pointer to a 1d array
can point to a 2d array, as opposed to can point to a 1d element
of a 2d array?
Read the section titled: Arrays.
[snip]
std::cout << typeid(*pa1i).name ;
outputs int[5]. There is no implicit conversion to pointer unless
it's
further dereferenced i.e: pali[0][0].

There is no implicit conversion in a typeid expression. According
to paragraph 3 of section 5.2.8 (Type identification) of the C++
standard:

When typeid is applied to an expression other than an lvalue of
a polymorphic class type, the result refers to a type_info object
representing the static type of the expression. Lvalue-to-rvalue
(4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
conversions are not applied to the expression. If the type of
the expression is a class type, the class shall be
completely-defined. The expression is not evaluated.

The output "int[5]" demonstrates that pali is a pointer to a
1-dimensional
array. In a context where the expression *pa1i is evaluated, the
resulting
1-dimensional array undergoes array-to-pointer conversion, resulting
in
a
pointer to int.
The output demonstrates its an array , not a pointer.
The type int[5] is not a pointer. As I said this is not implicitly
converted
to a pointer until its further dereferenced. And when it is converted
to
a
pointer it will be pointer-type: int*, not int (*)[5].

That's right, *pai1i is an array.
So why did you say it was a pointer? Its not a pointer its an array.

What I said (correcting for typos) was: pa1i is a pointer to an array,
*pa1i is an array, and when *pa1i (an array of int) is in a context
where array-to-pointer conversion is done, it is implicitly converted
to a pointer to int. That pointer to int points to the first element
of the array.
You said :
"The output "int[5]" demonstrates that pali is a pointer to a 1-dimensional
array."
Its not a pointer, which you still repeat in your correction, it's an
array.
Here is what Bjarne Stroustrup wrote in The C++ Programming
Language (page 91 of the Special Edition)

The name of an array can be used as a pointer to its initial
element. For example:

int v[] = { 1, 2, 3, 4 };
int* p1 = v; // pointer to initial element (implicitly converted)
int* p2 = &v[0]; // pointer to initial element
int* p3 = &v[4]; // pointer to one beyond last element
BS also said that a pointer of type char* can point to a single char or an
array of chars.
You think a char* cannot possibly point to an array of chars, which is a
direct disagreement with BS.

I agree with all BS has said in your quote , it does not in any way suggest
what you are suggesting.
The value of "typeid(pa1i).name()"
would indicate that pa1i is a pointer to int[5] (the value
returned by type_info::name() is implementation defined).
No its an array , it not a fucking pointer at all it's an array.

What output do you get for the following program?

#include <iostream>
#include <typeinfo>

int main() {
int (*pa1i)[5];

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

The output I get is

typeid(*pa1i)=A5_i
typeid( pa1i)=PA5_i

The output indicates that *pa1i is an array of 5 int and pa1i is a pointer
to an array of 5 int.
I can tell you without even compiling this I won't get the same output you
get.
*pa1i will give me ... int[5]
pa1i will give me .... int (*)[5]

What do you tihnk this proves? It outputs the pointer-TYPE. The pointer
doesn't even point to anything valid, its uninitialised.

This type of pointer can point to a 2d array or a 1d array but its more
general use is a pointer to a 2d array. Yes its type is pointer to 1d array,
because thats how pointers to arrays work in C++, see the section on arrays
which explains why an array is pointed to by a (n-1) dimensional type
pointer.

Why can't you just accept what is in the standards instead of being ignorant
to this? It's not irelevant as you have previously said.
The
type int[5] is not a pointer type. However, when used in a context
where array-to-pointer conversion is applied, a value of type int[5]
is implicitly converted to a pointer to int.
Your last 3 statements said it's a poiinter now you say its not a
pointer,
you can't accept that *pa1i returns an array because it proves the
standards
confirms it is a pointer to a a 2d array.

What I said was that *pa1i is an array and pali is a pointer to an
array. The result of the expression
typeid(*pa1i).name()
So if you accept what is written in the C++ standards then, when
dereferenced, a pointer to an array returns a pointed to (n-1) dim array.
If pa1i is derefernced it reutrns a 1d array, so the pointed to array is a
2d array.
(2-1) = 1d array.

If you do not accept this I cannot say anymore, its how the C++ language
works and its written in the C++ standards.

indicates that *pa1i is a 1d array of int; array-to-pointer
conversion is not applied to the operand of typeid (see the above
quote from the Type Identification section of the standard).
No if it pointed to a 1d array then (1-1) = 0 .

Additionally why is it possible to do :
int (*p)[5] = new int[5];
or
int arr[5][5] = {0};
p=arr;


C++ fully supports that this TYPE of pointer can be used to point to 2d
array.
Yes it can also be used to point to a 1d array but its more commonly used to
point to a 2d array


If you refuse to think of pointers to arrays as being generally (n-1) dim
than the pointed to array, then thats up to you. Please dont try to say
everyone who accepts this is wrong becuase a pointer type can only point to
an object of that type, that is simply incorrect.

In the statement

int *pi = *pa1i;

*pa1i is a 1d array of int to which array-to-pointer conversion
is applied, resulting in a pointer to int. Here is part of
paragraph 14 of section 8.5 (Initializers):

Otherwise, the initial value of the object being initialized is
the (possibly converted) value of the initializer expression.
Standard conversions (clause 4) will be used, if necessary, to
convert the initializer expression to the cv-unqualified
version of the destination type; no user-defined conversions
are considered.
And?
I don't know why you keep going on.
Accept what BS says, accept what the C++ standard says. Don't be like those
idiots around here who only argue because they are total arseholes who
cannot accept when they make mistakes.

It is initialised to point to a 2d array, with:
int a2i[3][5], (*pa1i)[5] = a2i;

a2i is a 2d array , not a 1d array.
An array is defined at allocation, not by a pointer that points to it.

Although a2i is a 2d array, when used in the initialization
expression array-to-pointer conversion is applied to it, and the
result is a pointer to the 1d array that is the first element of a2i.
The variable pa1i (a pointer to a 1d array) is initialized to that
pointer to a 1d array result.
The pointed to array is a 2d array, not a 1d array. The pointer type is
pointer to int[5], which does not point to an element, it points to a 2d
array. The reason its type is pointer to 1d array is because of the
rules
of the C++ language, the standards state:
When dereferenced a pointer ot an array returns the pointed to (n-1)
dimensional array.

You are partially right. The type of the initialization expression
a2i is a pointer to int[5]. However, you are wrong about it not
pointing to an element; it points to the first of the 3 int[5]
elements of the array named a2i. Here is paragraph 1 of section 4.2
(Array-to-pointer conversion) of the C++ standard:

An array element is a single object, not a sub-array.

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

The pointed to array is a 1d array because accessing what a pointer
to a 1d array points to accesses a 1d array. In this case, the 1d
array is an element of a 2d array.
Ok you carry on ignoring the C++ standards and Bjarne Stroustrup and many
other experts in the field. Thats your problem not mine, if you think you
are ever going to make me think you are correct and all these other good
sources of knowledge are total bullshit then you are mistaken.
 
P

Paul

A. Bolmarcich said:
When reading a quote from a programming language standard, it is a
good idea to read the whole quote, including parts that establishes
the context in which the quote applies. In this case the context
is polymorphic objects.
Are you a complete fucking idiot? !!!

"1.7 The C+ + object model [intro.object]
1 The constructs in a C + + program create, destroy, refer to, access, and
manipulate objects. An object is a
region of storage. An object is created by a definition (3.1), by a
newexpression
(5.3.4) or by the implementation
(12.2) when needed. The properties of an object are determined when the
object is created. An
object can have a name (3). An object has a storage duration (3.7) which
influences its lifetime (3.8). An
object has a type (3.9). The term object type refers to the type with which
the object is created. Some
objects are polymorphic (10.3); the implementation generates information
associated with each such object
that makes it possible to determine that object's type during program
execution. For other objects, the
interpretation of the values found therein is determined by the type of the
expressions (5) used to access
them"

*****The term object type refers to the type with which the object is
created. **** PERIOD


Its talking about fucking objects, NOT fucking only polymorphic objects, you
dumb fucking twat.





The type of pointer determines the type of value obtained when the
pointer is dereferenced, the change in the pointer value when it
is incremented, and the non-virtual member of a polymorphic object
that is accessed.
In C++ an objects' type is NOT determined by a pointer that points to it.
You were fucking wrong , you ARE fucking wrong and you cannot accept that
you fucking twat.
[snip]
According to the C++ standard, "int (*p3i)[3]" declares a "pointer
to an array of 3 int".
Its TYPE is pointer to array. What it points to can be null, or almost
anything.
You are obviously confusing its type with what it points to.

"int (*p3i)[3]" declares pointer to an array of 3 int.
No it declares a pointer of type poiner to array. It doesn't point to
anything valid until its been initialised.
Dereferencing
that pointer results in an array of 3 int.
Dereferencing it results in UB.

That's right, a pointer variable does not point to anything valid
until its value is set. Given the declaration
So you were wrong, once again you were speaking utter bullshit.


[snip]
A null pointer is a valid object and well defined in the C++ standards.

Here is paragraph 4 of section 1.9 (Program execution) of the C++
standard.

Certain other operations are described in this International
Standard as undefined (for example, the effect of dereferencing
the null pointer). [Note: this International Standard imposes no
requirements on the behavior of programs that contain undefined
behavior. ]

If you think that dereferencing the null pointer is defined, you
are thinking of a programming language other than C++.

In C++ a null pointer IS a valid object. I don't give a **** what you think
about dereferncing it.
Readers of this newsgroup should see exactly what is written in the
C++ standard. That is why I have included complete paragraphs from
it in my posts.

The majority of readers in this newsgroup are, like you, complete idiots and
I don't give a **** what they think.
 
P

Paul

cg_chas said:
Are you a complete fucking idiot? !!!
I don't think he is at all, but I am certain you are and I can prove it.
"1.7 The C+ + object model [intro.object]
1 The constructs in a C + + program create, destroy, refer to, access, and
manipulate objects. An object is a
region of storage. An object is created by a definition (3.1), by a
newexpression
(5.3.4) or by the implementation
(12.2) when needed. The properties of an object are determined when the
object is created. An
object can have a name (3). An object has a storage duration (3.7) which
influences its lifetime (3.8). An
object has a type (3.9). The term object type refers to the type with
which
the object is created. Some
objects are polymorphic (10.3); the implementation generates information
associated with each such object
that makes it possible to determine that object's type during program
execution. For other objects, the
interpretation of the values found therein is determined by the type of
the
expressions (5) used to access
them"

*****The term object type refers to the type with which the object is
created. **** PERIOD


Its talking about fucking objects, NOT fucking only polymorphic objects,
you
dumb fucking twat.
You have used polymorphism as the main point for your argument since you
cited
the Standard out of context. You surely don't understand this, but I make
a
point of showing it here for the world to see,

Here was your statement and supporting logic.

Paul said:
No, a pointer type doesn't define what is pointed to.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is created.
Some objects are polymorphic".
Out of an entire paragraph you chose to include a statement followed by a
reference to polymorphism that has abbsolutely no bearing on your
assertion.
You're a proven idiot, but the irrefutable proof is below.
In C++ an objects' type is NOT determined by a pointer that points to it.
You were fucking wrong , you ARE fucking wrong and you cannot accept that
you fucking twat.

Getting back to Paul's favorite example:
int* p = new int[5];

Using your very own logic from your above statement:
*****The term object type refers to the type with which the object is
created. **** PERIOD

For the above case of p which IS IN FACT an object:
p was "created" (as you so sloppily like to say), as a "pointer to int".

Using your very own logic from your other statement:
In C++ an objects' type is NOT determined by a pointer that points to it.
p was declared and initialized as a pointer to int so it is in fact a
pointer to
int and nothing else as per your very own statements.
No an array was created you fucking wrong idiot.
 
P

Paul

cg_chas said:
In C++ what a pointer points to depends on the pointer type. Here
is paragraph 1 of section 5.3.1 of the C++ standard:

No, a pointer type doesn't define what is pointed to.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is
created.
Some
objects are polymorphic".

Although some objects are polymorphic, this discussion has been
about arrays. Arrays are not polymorphic; an array type does not
inherit from another type. The element type of an array may be
polymorphic, but an array is not.

The quote wasn't posted because it mentioned polymorphic types, it
was
posted becuase it says:
"The term object type refers to the type with which the object is
created."

When reading a quote from a programming language standard, it is a
good idea to read the whole quote, including parts that establishes
the context in which the quote applies. In this case the context
is polymorphic objects.

Are you a complete fucking idiot? !!!
I don't think he is at all, but I am certain you are and I can prove it.


"1.7 The C+ + object model [intro.object]
1 The constructs in a C + + program create, destroy, refer to, access,
and
manipulate objects. An object is a
region of storage. An object is created by a definition (3.1), by a
newexpression
(5.3.4) or by the implementation
(12.2) when needed. The properties of an object are determined when the
object is created. An
object can have a name (3). An object has a storage duration (3.7) which
influences its lifetime (3.8). An
object has a type (3.9). The term object type refers to the type with
which
the object is created. Some
objects are polymorphic (10.3); the implementation generates information
associated with each such object
that makes it possible to determine that object's type during program
execution. For other objects, the
interpretation of the values found therein is determined by the type of
the
expressions (5) used to access
them"

*****The term object type refers to the type with which the object is
created. **** PERIOD


Its talking about fucking objects, NOT fucking only polymorphic objects,
you
dumb fucking twat.
You have used polymorphism as the main point for your argument since you
cited
the Standard out of context. You surely don't understand this, but I
make
a
point of showing it here for the world to see,

Here was your statement and supporting logic.

No, a pointer type doesn't define what is pointed to.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is
created.
Some objects are polymorphic".
Out of an entire paragraph you chose to include a statement followed by
a
reference to polymorphism that has abbsolutely no bearing on your
assertion.
You're a proven idiot, but the irrefutable proof is below.

An objects' type is defined when its created, it is not defined by
some
pointer that points to it.
You said :
"In C++ what a pointer points to depends on the pointer type."
This is complete nonsense because a pointed to object is not defined
by
a
type of pointer, pointing to it.

The type of pointer determines the type of value obtained when the
pointer is dereferenced, the change in the pointer value when it
is incremented, and the non-virtual member of a polymorphic object
that is accessed.

In C++ an objects' type is NOT determined by a pointer that points to
it.
You were fucking wrong , you ARE fucking wrong and you cannot accept
that
you fucking twat.

Getting back to Paul's favorite example:
int* p = new int[5];

Using your very own logic from your above statement:
*****The term object type refers to the type with which the object is
created. **** PERIOD

For the above case of p which IS IN FACT an object:
p was "created" (as you so sloppily like to say), as a "pointer to int".

Using your very own logic from your other statement:
In C++ an objects' type is NOT determined by a pointer that points to
it.
p was declared and initialized as a pointer to int so it is in fact a
pointer to
int and nothing else as per your very own statements.
No an array was created you fucking wrong idiot.
You are very confused. An array of int was _allocated_ (assuming success).

The object returned by new was not an array, it was, in fact, an object of
type
"pointer to int". This was the object that was used to "initialize" p.
The object/s created by new is a fucking array, you fucking idiot.
The fact that you say, "created" is most indicative that you are not
capable of
speaking intelligently about C++. Your confusion is yours and yours
alone.

I use created just like the C++ standards do, you fucking idiot.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is created."
 
P

Paul

cg_chas said:
The type of pointer determines the type of value obtained when the
pointer is dereferenced, the change in the pointer value when it
is incremented, and the non-virtual member of a polymorphic object
that is accessed.

In C++ an objects' type is NOT determined by a pointer that points to
it.
You were fucking wrong , you ARE fucking wrong and you cannot accept
that
you fucking twat.

Getting back to Paul's favorite example:
int* p = new int[5];

Using your very own logic from your above statement:
*****The term object type refers to the type with which the object is
created. **** PERIOD

For the above case of p which IS IN FACT an object:
p was "created" (as you so sloppily like to say), as a "pointer to
int".

Using your very own logic from your other statement:
In C++ an objects' type is NOT determined by a pointer that points to
it.
p was declared and initialized as a pointer to int so it is in fact a
pointer to
int and nothing else as per your very own statements.

No an array was created you fucking wrong idiot.
You are very confused. An array of int was _allocated_ (assuming
success).

The object returned by new was not an array, it was, in fact, an object
of
type
"pointer to int". This was the object that was used to "initialize" p.
The object/s created by new is a fucking array, you fucking idiot.
The fact that you say, "created" is most indicative that you are not
capable of
speaking intelligently about C++. Your confusion is yours and yours
alone.

I use created just like the C++ standards do, you fucking idiot.
1.7 The C++ Object Model states:
"The term object type refers to the type with which the object is
created."

Amazing that you are only capable of talking about the Standard, yet you
never
seem to actually read what it says beyond a single word or two that in
your mind
would seem to support your skewed views.

I realize now that when you say that you are not going to read my posts,
what
you really mean is that you are unable to understand what you read, so you
can't
regardless of your intent. Nevertheless, I will properly cite the
Standard.

From 1.8 The C++ object model:
"An object is created by a definition (3.1), by a new-expression (5.3.4)"
...

Since we are talking about a new-expression we will refer to your favorite
example: int* p = new int[5] which is well-defined in 5.3.4.

which you so eloquently state:
The object/s created by new is a fucking array, you fucking idiot.

5.3.4 New

1. "The new-expression attempts to create an object of the type-id (8.1)
or
new-type-id to which it is applied. The type of that object is the
allocated
type. This type shall be a complete object type, but not an abstract
class type or array thereof" ...

---> The type of that object is the _allocated_ type.

5. "When the allocated object is an array (that is, the
direct-new-declarator
syntax is used or the new-type-id or type-id denotes an array type), the
new-expression yields a pointer to the initial element (if any) of the
array. [Note: both new int and new int[10] have type int* and the type of
new
int[10] is int (*)[10]. ]

---> both new int and new int[10] have type " int * "

The type of object _yielded_ by the new-expression is "pointer to int".

You can say "an array was created" until you are blue in the face. The
Standard, however, defines explicitly what "created" means for the
specific case
of the pointer initialization / array allocation example.
[/QUOTE]

Yes I can because new int[5] creates an array.

I have no more to say to a fucking idiotic, serial misinterpreter like you.
 
P

Paul

A. Bolmarcich said:
On 2011-04-09, Paul <[email protected]> wrote:
In this sequence of followups:

- I wrote: "Dereferencing the null pointer is undefined behaviour."

- You replied: "A null pointer is a valid object and well defined in
the C++ standards."

- I replied with a paragraph from the C++ standard that gave
dereferencing of the null pointer as an example of an undefined
operation.

If you don't care what the effect of dereferencing the null pointer
is, why did you followup about it?
Why did you write? :
"Dereferencing the null pointer is undefined behaviour."

Because I said a null pointer is a valid object, you wrote this in a twisted
attempt to somehow suggest it was undefined.
As I said , I don't give a **** what you think about dereferencing it, its a
valid fucking object. An it points to exactly **** all.
This blows your whole fucking argument out the window because it further
proves that a valid pointer of type pointer-to-T doesn't always point to a
T.

You said an int* can only point to an int, and you are fucking wrong. Accept
it and stop being a total fucking arsehole.
 
J

Joshua Maurice

The majority of readers in this newsgroup are, like you, complete idiots and
I don't give a **** what they think.

Hey, at least we (they) are getting somewhere. He's dropped some of
his illusions of grandeur. Before it used to be everyone agreed with
him except the few idiots.
 
P

Paul

A. Bolmarcich said:
Why did you write? :
"Dereferencing the null pointer is undefined behaviour."

Because I said a null pointer is a valid object, you wrote this in a
twisted
attempt to somehow suggest it was undefined.
As I said , I don't give a **** what you think about dereferencing it,
its a
valid fucking object. An it points to exactly **** all.
This blows your whole fucking argument out the window because it further
proves that a valid pointer of type pointer-to-T doesn't always point to
a
T.

I did not make a twisted attepmt to suggest that it was undefined. What I
did was post paragraph 4 of section 1.9 (Program execution) of the C++
standard:

Certain other operations are described in this International
Standard as undefined (for example, the effect of dereferencing
the null pointer). [Note: this International Standard imposes no
requirements on the behavior of programs that contain undefined
behavior. ]

I accept exactly what is in the C++ standard, such as, the effect
of dereferencing the null pointer is undefined.

But this does not acknowledge what I said, that a null pointer is a valid
object.
You attempt to divert the conversation to what happens when the pointer is
dereferenced.

The argument is about what a pointer to an array points to, not what happens
when its dereferenced.
If you want to talk about what happens when pointer is dereferenced then
refer to the relevant section in the standards that fully explains what
happens when a pointer to an array is dereferenced.
When dereferenced, a pointer to an array yields an (n-1) dimensional array.

The idiotic thing is when I initially mentioned this , you said it was not
relevant section of the standards because it was speaking about
dereferencing a pointer to an array. It is in fact exactly the relevant
section of the standard that suits this argument.

Mistakes in C++ programs can be avoided by accepting exactly what
is in the C++ standard, rather than accepting a fallacy, such as
pointers and arrays are the same.

Well accpet what the standards states about dereferencing pointers to arrays
instead of avoiding it like the plague and perhaps you will make fewer
mistakes :)
 
P

Paul

A. Bolmarcich said:
On 2011-04-12 said:
The argument is about what a pointer to an array points to, not what
happens
when its dereferenced.
If you want to talk about what happens when pointer is dereferenced then
refer to the relevant section in the standards that fully explains what
happens when a pointer to an array is dereferenced.
When dereferenced, a pointer to an array yields an (n-1) dimensional
array.

A pointer to an array points to an array. What happens when a
pointer is dereferenced is given in paragraph 1 of section 5.3.1
(Unary operators):

The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer
to a function type and the result is an lvalue referring to the
object or function to which the expression points. If the type of
the expression is pointer to T, the type of the result is T.
[Note: a pointer to an incomplete type (other than cv void ) can
be dereferenced. The lvalue thus obtained can be used in limited
ways (to initialize a reference, for example); this lvalue must
not be converted to an rvalue, see 4.1.]

Because dereferencing a pointer to T results in a T, dereferencing a
pointer to an array results in an array.

It is important to undestand what the C++ standard means by a
pointer to an array. Here is a example from section 8.1 (Type
Names) of the C++ standard:

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

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

The declaration

int (*p3i)[3];

declares a pointer to an array. The declaration

int *pi;

declares a pointer to an int.

The output from the following program confirms that.

#include <iostream>
#include <typeinfo>

int main() {
int a3i[3], *pi=a3i, (*p3i)[3]=&a3i;

std::cout<<"typeid( pi )="<<typeid( pi ).name()<<std::endl;
std::cout<<"typeid(*pi )="<<typeid(*pi ).name()<<std::endl;
std::cout<<"typeid( p3i)="<<typeid( p3i).name()<<std::endl;
std::cout<<"typeid(*p3i)="<<typeid(*p3i).name()<<std::endl;
}
The idiotic thing is when I initially mentioned this , you said it was
not
relevant section of the standards because it was speaking about
dereferencing a pointer to an array. It is in fact exactly the relevant
section of the standard that suits this argument.

Here is what I wrote (near the bottom of Message-ID:
<[email protected]>)

As far as I can tell there in no recent thread titled "You missed
something"; there is one titled "You snipped something". Quotes
you posted there, such as

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

and

"the subscript operator [] is interpreted in such a way that E1[E2]
is identical to *((E1)+(E2))"

have nothing to do with declarations like

int *p = new int[4]

that my posts have been about.

Because that declaration does not contain either the * operator or
the subscript operator, parts of the C++ standard about those
operators are not relevant to that declaration.

That declaration initializes a pointer to int, named p, with the
pointer to int returned by "new int[4]". "new int[4]" returns an
pointer to int according to paragraph 1 of section 5.3.4 (New) of
the C++ standard. That paragraph ends with:

If the entity is a nonarray object, the new-expression returns
a pointer to the object created. If it is an array, the
new-expression returns a pointer to the initial element of
the array.

That is what is in the C++ standard; I accept exactly what is in
the standard.
No you dont accept the relevant sections of the C++ standards. You still say
the section that specifically details pointers to arrays is not relevant.
 
P

Paul

A. Bolmarcich said:
A. Bolmarcich said:
The idiotic thing is when I initially mentioned this , you said it was
not
relevant section of the standards because it was speaking about
dereferencing a pointer to an array. It is in fact exactly the relevant
section of the standard that suits this argument.

Here is what I wrote (near the bottom of Message-ID:
<[email protected]>)

As far as I can tell there in no recent thread titled "You missed
something"; there is one titled "You snipped something". Quotes
you posted there, such as

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

and

"the subscript operator [] is interpreted in such a way that E1[E2]
is identical to *((E1)+(E2))"

have nothing to do with declarations like

int *p = new int[4]

that my posts have been about.

Because that declaration does not contain either the * operator or
the subscript operator, parts of the C++ standard about those
operators are not relevant to that declaration.

That declaration initializes a pointer to int, named p, with the
pointer to int returned by "new int[4]". "new int[4]" returns an
pointer to int according to paragraph 1 of section 5.3.4 (New) of
the C++ standard. That paragraph ends with:

If the entity is a nonarray object, the new-expression returns
a pointer to the object created. If it is an array, the
new-expression returns a pointer to the initial element of
the array.

That is what is in the C++ standard; I accept exactly what is in
the standard.
No you dont accept the relevant sections of the C++ standards. You still
say
the section that specifically details pointers to arrays is not relevant.

What is in the C++ standard about pointers to arrays is not relevant to
the
statement

int *p = new int[4]

because there are no pointers to arrays in the statement, only pointers to
int. A relevant part of the C++ standards for that statement is paragraph
1 of section 5.3.4 (New) that I quoted (see above).
p is a pointer to an array of 4 ints, not only to one single int.
What is in the C++ standard about pointers to arrays is relevant to parts
of
a C++ program that use a pointer to an array, such as one declared by

int (*p1i)[5]
No the C++ standard is relevant to all C++ arrays. The standard defines the
above pointer type can point to a 2d array, and an int* can point to a 1d
array.


When people like Bjarne Stroustrup say that a char* can point to a single
char or an array of chars, who is more likely to be correct him or someone
like you who directly disagrees with this?
 
P

Paul

A. Bolmarcich said:
What is in the C++ standard about pointers to arrays is not relevant to
the
statement

int *p = new int[4]

because there are no pointers to arrays in the statement, only pointers
to
int. A relevant part of the C++ standards for that statement is
paragraph
1 of section 5.3.4 (New) that I quoted (see above).
p is a pointer to an array of 4 ints, not only to one single int.

No, p is a pointer to an int. If it were a pointer to an array of
4 ints, then the byte address that the result of the expression

p+1

points to would be the byte address that p points plus
4*sizeof(int). However, the byte address of what that expression
points to is the byte address that p points to plus sizeof(int).

Do you understand the difference between a pointer-type and what a pointer
points to?

Apparently not , let me explain:

p is a pointer to an array of 4 ints.
p is a pointer-type , pointer to int.
when dereferenced p retruns a single int , which is a single element of the
array it points to.
when incremented p increments sizeof(int), and will point specifically to
the next sequential element in the array.
If p returned 4*sizeof(int) when dereferenced it could not be indexed using
the subscript operator, as arrays are in C++.


What is in the C++ standard about pointers to arrays is relevant to
parts
of
a C++ program that use a pointer to an array, such as one declared by

int (*p1i)[5]
No the C++ standard is relevant to all C++ arrays. The standard defines
the
above pointer type can point to a 2d array, and an int* can point to a 1d
array.

I did not state that the C++ standard was not relevant to all C++
arrays. I have stated that what is in the C++ standard about
pointers to arrays is not relevant to a C++ statement where there
are no pointers to arrays.

Exactly where (section and paragraph) does the C++ standard state
that a pointer to a 1d array can point to a 2d array, as opposed
to can point to a 1d element of a 2d array?

If a pointer to a 1d array could point to a 2d array, the last
initialization in the declaration

int a2i[3][5], (*p2i)[3][5] = &a2i, (*p1i)[5] = p2i;

that tries to initialize a pointer to a 1d array with a pointer
to a 2d array would be allowed, but it isn't.

Similarly, if a pointer to int could point to a 1d array of int,
the last initialization in the declaration

int a1i[5], (*p1i)[5] = &a1i, *pi = p1i;

would be allowed, but it isn't.
When people like Bjarne Stroustrup say that a char* can point to a single
char or an array of chars, who is more likely to be correct him or
someone
like you who directly disagrees with this?

Details are sometimes omitted from what is said about C++. Bjarne
Stroustrup went into details in "The C++ Programming Language".
According to that book (page 91 of the Special Edition): "The name
of an array can be used as a pointer to its initial element."

Part of an example on the next page of the book is

char v[] = "Annemarie";
char* p = v; // implicit conversion of char[] to char*

When Bjarne Stroustrup goes into the details, he says that the
name of an array is converted to a pointer to an element of the
array, not to a pointer to the array. In C++ pointers are typed;
"pointer to char" and "pointer to array of char" are different
types.

So according to you this is incorrect:

"The pointer declaration char *p, on the other hand, requests a place which
holds a pointer, to be known by the name ``p''. This pointer can point
almost anywhere: to any char, or to any contiguous array of chars, or
nowhere "

Im sorry but I agree with the above quotation , and if you disagree then I
diasagree with you and I think it is more likely that you are incorrect than
the source of this quotation.
 
G

gwowen

No, p is a pointer to an int.  If it were a pointer to an array of
4 ints, then the byte address that the result of the expression

  p+1

points to would be the byte address that p points plus
4*sizeof(int).  However, the byte address of what that expression
points to is the byte address that p points to plus sizeof(int).

Hey. There's a novel point. No-one has ever made that observation to
Paul before. That'll probably convince him.
At last, our long national nightmare is over.
 
I

Ian Collins

Hey. There's a novel point. No-one has ever made that observation to
Paul before. That'll probably convince him.
At last, our long national nightmare is over.

Do you really expect someone who don't know whether the C++ language has
one or more standards to grasp such a clear and simple bit of logic?
 
P

Paul

Ian Collins said:
Do you really expect someone who don't know whether the C++ language has
one or more standards to grasp such a clear and simple bit of logic?
That would be you then. :)
 
G

gwowen

Do you really expect someone who don't know whether the C++ language has
one or more standards to grasp such a clear and simple bit of logic?

Well, no. (Actually I was being facetious - this point has been made
hundreds of times before, and that's just by those people whos posts I
read. My point, which I concede to be unclear, as sarcasm and
facetiousness so often are on Usenet, was that since Paul was not
swayed by this argument the first 100 times, making it again was a
waste of perfectly good electrons)
 

Ask a Question

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

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

Ask a Question

Members online

Forum statistics

Threads
473,776
Messages
2,569,602
Members
45,182
Latest member
BettinaPol

Latest Threads

Top