Re: Problem with array objects
On 2011-06-16, Paul <pchristor@yahoo.co.uk> wrote:
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnivkjjl.vql.aggedor@earl-grey.cloud9.net...
[snip]
Defining how to declare a pointer in C++ is part of the definition of
what a pointer is in C++. I wrote: 'See 8.3.1 (Pointers) and
the numerous occurrences of "pointer" in the C++ standard.' You are
ignoring the numerous occurrences of "pointer" in the C++ standard.
Defining rules for driving a car is not the same thing as defining what a
car is.
What you seem to be suggesting here is that every occurence of the word
"pointer" in the C++ standard is actually part of the definition of a
pointer.
Every occurrence of the word "pointer" in the C++ standard specifies
how an implementation of C++ is to treat a pointer in the context
described by that part of the C++ standard. All those parts of the
C++ standard taken together define what a pointer is in C++.
What a pointer is in C++ is not defined in a single place in the
C++ standard. Just as what an int is in C++ is not defined in a
single place: one place defines how to declare an identifier of type
int and other places define the results of operators on an int.
What a pointer is, is defined in the C standard.
An "int" is a type, it is probably defined in the section "Types".
What a pointer is in C++ is defined in the C++ standard, not in the
C standard. C++ is based on C; C++ is not a copy of C.
[snip]
What is in 8.3.1 is part of the definition of what a pointer is in C++.
It is the part about how an identifier of type pointer is declared.
Other parts of the C++ standard define the results of operators on a
pointer.
A pointer is defined as a compound type re 3.9.2:
"3.9.2 Compound types [basic.compound]
1 Compound types can be constructed in the following ways:
- arrays of objects of a given type, 8.3.4;
- functions, which have parameters of given types and return void or
references or objects of a given
type, 8.3.5;
- pointers to void or objects or functions (including static members of
classes) of a given type, 8.3.1;"
Note that pointer is in italics so it's defined here. 8.3.1 gives further
information about the rules for declaring pointers but it doesn't define
what a pointer is.
The above defines a pointer to be a compund type.
In the same section, re paragraph 3, there is further information on the
definition of a pointer it begins:
"3 A pointer to objects of type T is referred to as a "pointer to T.""
So what does this mean....
With the following two arrays(and pointers to them) examples:
a) T* pT1 = new T[101];
b) T (*pT2)[101] = (T (*)[101]) new T[101];
Ok so pT1 and pT2 are both pointers to objects of type T but in a different
way so lets see how this compares to the definiton in the C++ standard.
No, pT1 and pT2 are not both pointers to objects of type T. pT1 is
a pointer to an object of type T. pT1 is initialized to the value of
the T* returned by new T[101]. pT2 is a pointer to an array of 101 T.
pT2 is initialized by an explicit type conversion that overrides the
type checking done by C++. A C++ implementation rejects the statement
T (*pT3)[101] = pT1;
because a pointer to T is not a pointer to an array of T.
The explicit type conversion may result in undefined behavoir, as in
dereferencing the pointer declared by the following statement.
T (*pT4)[101] = (T (*)[101]) 37;
pT1 is a pointer to objects of type T and is referred to as a pointer to T.
pT2 is a pointer to objects of type T(*)[101] and is referred to as a
pointer to T(*)[101].
The value of pT1 may validly be the address of a single object of type
T, not multiple objects of type T. The result of dereferencing pT1 is
a single object of type T, not multiple objects of type T. According
to the start of paragraph 1 of 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.
Note that the result is "the value" (singular) not "the values"
(plural).
Similarly, the value of pT2 may validly be the address of a single
object of type array of 101 T, not multiple objects of that type.
This seems to me to be exactly as I have explained previously, the
difference is whether the array is seen as an array of integer objects or a
single array-object.
Whether an array or a sub-object in that array is pointed to is
determined by the type of the pointer. For an array of 10 int, a
int(*)[10] may point to the array object while a int* may point to
a sub-object in the array object.
Any argument that one is more correct than the other is nothing more than
pedantic quibling over terminology, I maintain that the terminology I use is
genrally accepted terminology and used all across many programming
communities. Many programmers refer to pT1 as a pointer to an array, though
it doesn't point to an array-object, it points to an array of T objects, BS
included.
The many programmers who refer to pT1 as a pointer to an array are
technically incorrect. Programmers dealing with C++ at the level
of detail of the C++ standard are careful about the details. Those
who understand C++ at the level of detail of the C++ standard are
less likely to be confused about what a pointer to an array is.
Exactly where does BS state than pT1 points to an array of T objects,
as opposed to being able to point to a T object that is an element
in an array of T? Here, again, 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
Note that each pointer is to an element in the array or one beyond
the last element, the pointers are not to the array. A pointer to
the array named v in the example would be:
int (*p)[4] = &v;
There is a further problem in your use of terminology and it goes back to
the old argument about the terminology in the standards not being the same
as the terminology used by every day programmers. If the standards states
that X will be referred to as Y. It means that is how it will be used in
the context of the standard, it is not stating that this is the terminology
every day programmers must use and this is a big problem with many of the
flame wars in these forums.
An example is the term "object". If I am discussing inheritance or some
other aspect of OOP in C++ , and you tell me an int is an object because the
standard says so then you are using this out of context. In the context of a
discussion about OOP an object is an instance of a class-type , not an int
or a char.
My first post to this thread was a quote from the C++ standard about
what the expression
new int [4]
returns. See
http://groups.google.com/group/comp.lang.c++/msg/dc6879307c277751?hl=en
Since then I have been responding to followups you have made to my
posts. I have answered questions you have asked me (include "Are you
a complete fucking idiot? !!!"). See
http://groups.google.com/group/comp.lang.c++/msg/bc5aae365871a528?hl=en
I have responded to questionable statements you have made about what I
have written.
Here, I'll respond to a questionable statement you wrote just above:
"If I am discussing inheritance or some other aspect of OOP in C++ ,
and you tell me an int is an object because the standard says so then
you are using this out of context." I have never told you that an
int is object because the standard says so when you were discusssing
inheritance or some other aspect of OOP in C++.
In general the problem is there are too many wanabees who think they know it
all and try to correct people on the most pedantic of terminology "errors"
because they have nothing better to do.
Unfortunately for many people in this case they can try all they want to say
that p(in the following) does not point to an array but they would be wrong
becuase it points to an array of integer objects.
int* p = new int[101];
I don't know it all. I am willing to share the knowledge of C++ that
I have. When someone asks a question in comp.lang.c++ and none of
the other responses have included some important information, such as
what is in the C++ standard about the issue, I'll post the information
I have.
With
int* p = new int[101];
p points to an int, not to an array of int (the initialization
expression returns a pointer to int). What points to an array
of 101 int is a int(*)[101]. If you think that is nothing more than
pedantic quibling over terminology, say that and be done with it
(rather than flame by calling someone a "complete fucking idiot").
To suggest that this pointer does not point to an array because the standard
states it will be referred to as "a pointer to integer" is complete
nonsense. It points to an array of integer objects, therefore it's a pointer
to an array of integer objects.
You may consider what is in the C++ standard as complete nonsense. I
accept what is actually in the C++ standard as the definition of C++.