Re: Problem with array objects
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnivpnok.2phk.aggedor@earl-grey.cloud9.net...
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++.
No it doesn't I can speak about C++ and use the term "pointer" to mean
Instruction pointer. The standard does not define the english langauge nor
does it define programming terminology.
It defines a pointer ...drumroll.... where it is defined......... in
italics.
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
Nonsense pT1 and pT2 both point to 101 int objects, they both point to
exactly the same type of dynamically allocated memory.
T (*pT3)[101] = pT1;
Only you are daft enough to assume this is possible without a cast.
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):
I just told you what the standard states. I repeat:
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].
Are you dsisagreeing with this? Or are you trying to go off on a different
direction and avoid the facts by blabbering on about the value of pT1 and
pT2?
Both pointers have the same value , the starting address of the array.
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.
It doesn't matter what the unary operator does. This does not define what a
pointer is.
Again you are taking stuff out of context.
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.
Well the C++ standard and Bjarne Stroustrup are both techincally incorrect
in your opinion.
I'm sorry but I cannot accept your nonsense they are not techincally
incorrect it is you who is incorrect because you do not understand the
english language properly.
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)
char* - pointer to a char or an array of char.
http://www2.research.att.com/~bs/glossary.html
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").
Well TBH you are a fuckin idiot if you cannot see that 'p' points to more
than one integer object.
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++.
I repeat my quote for you:
"3 A pointer to objects of type T is referred to as a "pointer to T.""
It says OBJECTS not single object. It is you who does not accept what the
standard states. The standards support me not you.