Problem with array objects

[hanukas]

No its a pointer to 7 integers.

Hey, Paul.. pssst.. I have some code for you:

int compute(int *p)
{
// what does "p" point to here?

Tell me ASAP what the "p" points to, please.

 

[Paul]

No its a pointer to 7 integers.

Hey, Paul.. pssst.. I have some code for you:

int compute(int *p)
{
// what does "p" point to here?

Tell me ASAP what the "p" points to, please.
...................................................................................

I dunno , maybe its a null pointer and points to nothing.

 

[hanukas]

Hey, Paul.. pssst.. I have some code for you:

int compute(int *p)
{
    // what does "p" point to here?

Tell me ASAP what the "p" points to, please.
............................................................................ .......

I dunno , maybe its a null pointer and points to nothing.

Wrong! It points to array of herring. xD

 

[Paul]

Hey, Paul.. pssst.. I have some code for you:

int compute(int *p)
{
// what does "p" point to here?

Tell me ASAP what the "p" points to, please.
...........................................................................
.......

I dunno , maybe its a null pointer and points to nothing.

Wrong! It points to array of herring. xD

No that would be a :

 

[Paul]

[snip]

The C++ sees it as: "An object of array type contains a
contiguously allocated nonempty set of N sub-objects of type T."
Pointing to an array is pointing to an object of array type.
Pointing to a sub-object in an array is pointing to something other
than an object of the array type of the array that the sub-object is
in.

You have quoted some text from that seems to describe an object of
array
type.
As I said , and you have proved me correct, you can only see an array
as
"a
single array type object". You cannot see it at as array of integer
objects( or whatever type it is).

I have quoted the C++ standard. Seeing it as the C++ standard does
is the proper way to see it when discussing C++, such as in the
comp.lang.c++ newsgroup. Seeing it another way is seeing it in a
way different from the C++ standard.

This is not a definition of the term "array", this piece of text you have
quoted is not the C++ std's way of saying an array is definitely not an
sequence of objects, this is saying and array TYPE object is ....and it
doesn't mean this is the only possible way to consider an array.

Because an array is an object of array type, and not of any other
type, what the C++ standard states about an object of array type is
about an array.

What I quoted says that an array is a sequence of objects. The
phrase used in the standard is "a contiguously allocated set of
sub-objects". Here is part of a standard definition of the word
contiguous (the word from which the adverb contituously is derived):
"next or together in sequence" (from
http://oxforddictionaries.com/definition/contiguous). The
sub-objects an (object of type) array contains are together in a
sequence.

The C++ standard considers an array to be a sequence of sub-objects.
That is what an array should be considered to be when discussing C++.

With the following code..
int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

Both the pointers point-to the first element in the array, and both
pointers
also point-to the array of integer objects. They are just different
types
of
pointers.
They both point to exactly the same location.

Both pointers do not point to the first element of the array. p1
points to the first element of the array; p2 points to the array.
An array is not the same as its first element.
The address of an array is the same as the address of the first
element,
and
a pointer is this address.

The first element of an array is at the same memory location as the
array. The value of a C++ pointer is not only a memory location; it
is a typed memory location.

Rubbish the value of a pointer object does not contain any typeinfo. Its
a
simple integer value that represents the address of the pointed to
object.

The typeinfo is associated with the type of the pointer. In C++ a
pointer is not a simple integer value; it a typed value.

[Continuing with what I wrote in a single paragraph that you split.]

They point to exactly the same location.
The type of a pointer does not define what is pointed to.

In C++ the type of the pointer determines the type of the result of
dereferencing the pointer. Here, again, is what the C++ standard
states about the unary * operator: "If the type of the expression is
pointer to T, the type of the result is T."

If the type of the expression is a pointer is to an array of T, the
result of dereferencing its is type array of T. An attempt to access
the result of dereferencing a pointer to array of T when the value of
the pointer is not the address of an array of T object is undefined
behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
standard).

These posts are long enough without having to mention undefined
behavior when a value is not valid.

They both point to exactly the same place and they both point to
exactly
the
same array. Whether you view it as pointing to an array of pointing to
the
first element is just a POV.

They do not both point to exactly the same array. One points to an
array; the other may point to an element of that array. The point of
view of the C++ standard is that a

int (*)[]

points to an array of int while a

int *

points to an int, the int it points to may be an element in an array
of int.

This is completely made up. Where does the standard define that a pointer
type defines what is pointed to?
In fact where does the C++ standard define the term "points to"? It
doesn't.

One place the C++ standard uses the term "points to" is paragraph 2 of
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.8) of type T
(that is, not a base class subobject)."

"Points to" the start of a storage location is what a value of a
pointer type does. A pointer to int points to an int, accessing what
it points to when its value is not the address of an int is undefined
behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
standard.)

[snip]

The declarations were

int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

p1 is a pointer to an integer.

No its a pointer to 7 integers.

The type of p1 is int*; it is a pointer to int. The values of p1 and
p2 are the same storage location. Because p1 and p2 havd different
types, they point to different entties. p1 to and int and p2 to an
array of 7 int.

Saying that a pointer is to whatever is at the storage starting at
the value of the pointer ignores the fact that C++ pointer are typed.
Ignoring the pointer type would mean that for the declaration

int arr[3][5], *p;

setting the value of p to the address of the first integer in the
2-dimensional array would mean that p is a pointer to 1, 5, and 15
integers at the same time. It is a pointer to 15 integers because
15 were allocated starting at the storage location that p has as
its value. It is a pointer to 5 integers because the first of 3
arrays of 5 integers were allocated starting at the same storage
location. It is a pointer to 1 integer because the first integer
in the first of 3 arrays of 5 integers were allocated starting at
the same storage location.

For the declaration

int arr[3][5][7][9][11], *p;

setting the value of p to the address of the first integer in the
5-dimensional array would mean that p is a pointer to 1, 11, 99,
693, 3465, and 10395 integers at the same time.

A pointer to a member of a POD (plain old data) struct is a similar
situation. Ignoring its type, with

struct s_t {
int a, b, c, d, e;
} s;
int* pi = &s.a;

pi points to 5 integers.

With

struct s_t {
int a, b;
double c, d
long e;
} s;
int* pi = &s.a;

pi points to 2 integers, 2 doubles, and a long. What versitility
an int* has in a view that ignores the pointer type!

Because pointers are typed in C++, an int* points to an int. Just
because a pointer to int is treated as if it is to an element of an
array of int when an integral value is added to the pointer does not
mean that it does not point to an int.

This is similar to just because array-to-pointer conversion is
implicitly done in some contexts that an array is the same as a
pointer.

Accessing what p2 points to also accesses the same integer.
They are just different types of pointer but they both point to exactly
the
same thing.

p1 and p2 do not point to the same thing. p1 points to an int, p2
points to an array of int. If p1 an p2 pointed to the same thing,
it would not be necessary to dereference p2 twice to get the same
int that is gotten by dereferencing p1 once.

[snip]

An element in an array has a different type than the array the
element is in. The type of p1 is int*. When p1 points to an element
of an array of int, it is pointing to an an int, not to an array.
The type of a pointer to an array of int is of the form int(*)[].
The C++ standard is clear about this in the following example from
8.1 (Types).

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.

That is the TYPE of pointer, nobody is disputing the pointer TYPE. But a
pointer TYPE does not define what is pointed to by that pointer.

Writing, as you did above that "No its a pointer to 7 integers." as a
response to "p1 is a pointer to an integer.", where p1 is to type
int*, is disputing that in C++ the result of dereferencing a pointer to
T is a T, as opposed to many Ts. A pointer type defines what may be
validly pointed to. Dereferencing a pointer to T whose value is not
an address of T is undefined behavior.

A pointers' type simply tells us that that pointer is capable of
addressing
objects of the given type.
For example:
char* cp;
This pointer is capable of addressing char objects, it doesn't point to a
char object.

The value cp may validly be the address of a char object, the address
of a char object +1, or NULL. Dereferencing cp when its value is not
the address of a char object is undefined behavior. These posts are
long enough without having to mention undefined behavior when a value
is not valid.

The distinction between a pointer to an array and a pointer to an
element of that array is important for multidimensional arrays as
arrays of arrays in C++. The declaration

int x[3][5];

declares an array of 3 array of 5 int. The expression x[j] is
equivalent to *(*(x+i)+j). When that expression is evaluated

This is not what the Std says. The standard says that each subsctipt will
be
calucalated individually.
i has a multiplier of 5xsizeof(int), j has the multiplier of
1xsizeof(int).

Where is what follows are the subscripts not calculated individually?

They have different types, but they both point to the same location.

In C++ pointers are typed; they are not only a storage location value.
The type of the pointer determines type used when accessing what the
pointer points to.

Consider a stack frame pointer, pointing to the stack. It doesn't
actually
point the whole stack at the same time but nonetheless its still
considered
to be pointing to the stack.

There is a significant difference between a stack frame pointer and a
C++ pointer: a C++ pointer is typed. In C++, the result of
dereferencing a pointer to T, where T is a type, is a T.

No, dereferencing a pointer of type pointer-to-T, will result in a T
if
it
points to a valid T object.
The pointer type declares a pointer object that can address an object
of
the
decalred type , for example:
int *p = 0;
p = &ix; /*assume x is valid int*/
p = new int[64];

What I have written is about what a C++ compiler does, along the
lines of what the C++ standard does in the folliwng sentence about
the unary * operator: "If the type of the expression is pointer to T,
the type of the result is T." These post are long enough without
adding possible undefined behaviors when the program runs due to the
value of a pointer to a non-polymorphic type.

This is explaining just what I said, if the type of the pointer is T then
derefernecing it addresses a T.
Assuming it points to a valid T type object.
This is not defining what p points to. p points to a location and
whatever
is stored there is what is pointed to.

Whatever is at the storage location that is the value of a pointer to
T is treated as being of type T. The type of the pointer defines how
what is pointed to is treated. If what is at the storage location is
not an object of the appropriate type, the behavior is undefined.
These posts are long enough without having to mention undefined
behavior when a value is not valid.

Here the pointer p is declared to be a pointer of type ptr-to-int, it
means
this pointer must be capable of pointing to a valid int object., It has
nothing to do with what it points to.
The above the pointer is shown pointing to nothing, an integer and an
array
of integers.

What is shown is p having the null pointer value, pointing to an
integer, and pointing to the first integer in an array of integers
(the result of the expression (new int[64]) is a pointer to int,
not a pointer to array of int).

No what is returned from the new expression is a pointer to the first
element *of an array* of integers.
When the pointer is used as a pointer to the array like so:
p[3];
The expression is evaluated as:
*(p+ 3xsizeof(int))
Where p is a pointer to the beginning of the array , and the offset to
the
individual element is added.

The pointer to the first element of the array is a pointer to int (type
int*). The expression

(p + 3xsizeof(int))

is a pointer to the 3xsizeof(int) element relative to the array element
that p is treated as pointing to. If p points to the first element of
and array and sizeof(int) is 4, then

(p + 3xsizeof(int))

points to the 13th element of the array (first plus 12).

Pointers in C++ are typed. The storage location that is pointed to
when adding a pointer and an integral value depends on the pointer
type.

This pointer is used as a pointer to the array, not to only just one
element. And it can be used as a pointer to the array because it points
to
an array.

In the example, the pointer is not used as a pointer to an array of
int. p is a pointer to int. It may point to an element in an array
of int. A pointer to an element in an array of int is not same as a
pointer to the array. The former is of type int*; the latter is of
type like int(*)[64]. If p could be used as a pointer to an array (of
64 int), the following would be allowed, but it isn't.

int (*parr)[64] = p;

Yes its TYPE is int*, but this does not mean it can only point to one
single
integer. Its type does not define what it points to.

The type of a pointer defines what may be validly pointed to. An int*
may validly point to one single integer.

Well you have said that, becuase it is of type int*, it can only point to
an
int.
Now you are saying it is undefined what it points to.
I repeat..the pointer type does not define what is pointed to.

I can repeat, too. As I wrote above, where cp is of type char*

The value cp may validly be the address of a char object, the address
of a char object +1, or NULL. Dereferencing cp when its value is not
the address of a char object is undefined behavior. These posts are
long enough without have to mention undefined behavior when a value
is not valid.

You are shortening the term a "pointer type ptr-to-T" to mean the same as
a
"pointer to T". But the two terms do not mean the same thing.
One term is specifically describing the pointer type. The other is
referring
to whatever is at the location pointed to.

I have not used the term "ptr-to-T". Where is it in the C++ standard?

The value of a pointer to T, where T is a non-polymorphic type, may
validly be the address of an object of type T, the address of an object
of type T +1, or NULL. Dereferencing a pointer to T when its value
is not the address of an object of type T is undefined behavior. These
posts are long enough without having to mention undefined behavior when
a value is not valid.

The term "pointer" is not redefined because C++ pointers are typed.

A pointer is defined in the C standard and C++ inherits this defintion. A
pointer of type char* can point to a single char, and array of chars or
nothing at all. This is the view of the C standard and also Bjarne
Stroustrup in one of his C++ books.

When I run a C compiler on the statement that tries to set a char*
to point to an array of char, that is, set the value of a pointer
to char to the address of an array of char, as in

char arr[4], *pc = &arr;

I get a diagnostic message. Setting a char* to point to an element
in an array of char, that is, set the value of a pointer to char to
the address of an element of an array of char, as in

char arr[4], *pc = &arr[0];

is allowed.

In a previous post you partially quoted a glossary entry for char*
by Bjarne Stroustrup. What you quoted omitted: "Typically assumed
to point to a C-style string. Prefer a standard library string over
a C-style string when you can. TC++PL 2.3.3, 13.5.2."

The context of the glossary entry is C-style strings. The glossary
did not contain similar entries for other specific types, such as
int*, or an entry for T* that states a T* is a pointer to a T or to
an array of T.

Allowing

char v[] = "Annemarie";

is a special case for arrays of char and C-style strings.

When writing at a detailed level, Bjarne Stroustrup is careful
about the details, as in the following from an example on page
91 of the Special Edition of "The C++ Programming Language".

int v[] = { 1, 2, 3, 4 };
int* p1 = v; // pointer to initial element (implicit conversion)

Note that p1 is a pointer to the initial element, not a pointer to
the array.

In an eariler edition of the same book he wrote (page 53 of the
second edition):

Pointers to arrays and pointers to functions unfortunately need a
more complicated notation.

int* pi;
char** cpp; // pointer to pointer to char
int (*vp)[10]; // pointer to array of 10 ints
int (*fp)(char, char*); // pointer to function
// taking (char, char*) arguments
// and returning int

An int(*)[] points to an array of int; a int* does not, but it may
point to an element in an array of int.

With an array like so:
[int][int][int][int][int][int][int][int]
If a pointer 'p' points to the beinning of this array then the
expression:
p+1;
points to the second element.
p+2;
points to the third element, and so on.

The pointer 'p' points to an array of integers, not only one single
integer.
The TYPE of 'p' can only be int*, because if it were of type int (*)[8]
then
p+2 would point away past the array.

The pointer p points to an int. It is the semantics of the binary +
operator that p+i points to the i-th element of an array when p
points to the first element of the array. Those semantics also treat
an int(*)[8] as pointing to an element in an int[][8] array when an
integral value is added to an int(*)[8].

The pointer 'p' is used as a pointer to an array of integers, it could
not
be used as a pointer to an array if it only pointed to one single object.
It is a different concept from pointing to one single array type object.

The pointer p cannot be used as a pointer to an array of integers. If
it could, the last initialization in the following declaration would be
allowed, but it isn't.

int arr[4], (*parr)[4] = &arr, *p = parr;

The pointer p points to a single int type object. It may point to an
element in an array of int. In which case, it is pointing to a single
int in that array.

When p is pointing to a single int in an array, it due to the
semantics of adding a pointer and an integral value that (p+1) points
to the next element in the array. Pointing to an element in an array
is a different concept than pointing to an array.

The C++ standerd does not disgaree with me but it disagrees with you.
Whether tthe C++ standard is right or wrong, whether you are right or wrong
, IDC but I know that an int* can point to, a single int, an array of
integers, or nothing at all.

 

[Paul]

[snip]

The C++ standerd does not disgaree with me but it disagrees with you.
Whether tthe C++ standard is right or wrong, whether you are right or
wrong
, IDC but I know that an int* can point to, a single int, an array of
integers, or nothing at all.

Exactly where does the C++ standard disagree with me? I have quoted
paragraphs from it that support what I have claimed about C++.

The C++ standard is right when the subject matter is what is required
of implementations of C++. Something neither explictly stated in nor
inferred from the C++ standard is not part of C++.

Well lets start with your definition of a pointer.
The C++ standard defines that it's based on the C language. Pointers are not
defined in the C++ standard , they are defined in the C standard.

You can quote stuff from the C++ standard all day but these quotes mean
nothing if they are taken out of context.

What is a pointer?
According to you a pointer of type X* , points to an X and can point to
nothing else. I don't care even if the C++ standard did agree with that, its
simply wrong.
It can be proved wrong with the simple example of a null pointer:
X* p = 0;
You argument is based upon a twisted misinterpretation of the C++ standards
and it ignores simple facts.

 

[Paul]

[snip]

The C++ standerd does not disgaree with me but it disagrees with you.
Whether tthe C++ standard is right or wrong, whether you are right or
wrong
, IDC but I know that an int* can point to, a single int, an array of
integers, or nothing at all.

Exactly where does the C++ standard disagree with me? I have quoted
paragraphs from it that support what I have claimed about C++.

The C++ standard is right when the subject matter is what is required
of implementations of C++. Something neither explictly stated in nor
inferred from the C++ standard is not part of C++.

Well lets start with your definition of a pointer.
The C++ standard defines that it's based on the C language. Pointers are
not
defined in the C++ standard , they are defined in the C standard.

Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and
the numerous occurrences of "pointer" in the C++ standard. Although
C++ is based on C, C++ is not a superset of C. Some valid C programs
are not valid C++ programs, even some C programs that do not use an
identifier that is a keyword added to C++.

In the following section of the C++ :
8.0) Declarators
8.3) Meaning of Declarators
8.3.1) Pointer

8.3.1 is a subsection of 8.3 , which is a subsection of 8.0

The whole purpose of this section of the C++ standard is to define
declarators. It does not define a pointer , it defines how to declare a
pointer.
I think this confirmed when you look at the content in section 8.3.1:

"8.3.1 Pointers [dcl.ptr]
1 In a declaration T D where D has the form
* attribute-specifieropt cv-qualifier-seqopt D1
and the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T," then the type of the
identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer to
T." The cv-qualifiers apply to the pointer
and not to the object pointed to. Similarly, the optional
attribute-specifier (7.6.1) appertains to the pointer
and not to the object pointed to."

What in the C++ standard have I taken out of context? For the most
part I have quoted entire paragraphs from the standard in order to
retain the context.

Well for a start you have interpreted 8.3.1 as the definition of a pointer,
when it actaully defines a pointer declarator.
There is a big difference in defining what a pointer is, and defining how to
declare one.

So this is out of context as the context of the discussion was the
definition of a pointer, which more specifically means the definition of
what a pointer is , not how to declare one.

Saying that a pointer of type X* points only to an X is a
simplification. Two posts ago, I wrote

The value of a pointer to T, where T is a non-polymorphic type, may
validly be the address of an object of type T, the address of an object
of type T +1, or NULL. Dereferencing a pointer to T when its value
is not the address of an object of type T is undefined behavior. These
posts are long enough without having to mention undefined behavior when
a value is not valid.

There is no twisted misintpretation here.

Yes it is , where does the C++ standard define a pointer as you've defined
it above?

If there is a conflict between what is in the C++ standard and
"simple facts", it is what is in the C++ standard that is correct for
the C++ programming language.

There is no conlift in the standards, its the way you interpret the
standards.
The problem seems to be that you cannot accept the defintion of a pointer
,which is inhereted from the C standard.

 

[Paul]

On 2011-06-11, Paul <[email protected]> wrote:

[snip]

Well lets start with your definition of a pointer.
The C++ standard defines that it's based on the C language. Pointers
are
not
defined in the C++ standard , they are defined in the C standard.

Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and
the numerous occurrences of "pointer" in the C++ standard. Although
C++ is based on C, C++ is not a superset of C. Some valid C programs
are not valid C++ programs, even some C programs that do not use an
identifier that is a keyword added to C++.

In the following section of the C++ :
8.0) Declarators
8.3) Meaning of Declarators
8.3.1) Pointer

8.3.1 is a subsection of 8.3 , which is a subsection of 8.0

The whole purpose of this section of the C++ standard is to define
declarators. It does not define a pointer , it defines how to declare a
pointer.
I think this confirmed when you look at the content in section 8.3.1:

"8.3.1 Pointers [dcl.ptr]
1 In a declaration T D where D has the form
* attribute-specifieropt cv-qualifier-seqopt D1
and the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T," then the type of the
identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer
to
T." The cv-qualifiers apply to the pointer
and not to the object pointed to. Similarly, the optional
attribute-specifier (7.6.1) appertains to the pointer
and not to the object pointed to."

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.

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

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

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.

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.

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.

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];

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.

 

[Paul]

[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, 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.

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.

 

[Keith H Duggar]

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++.

Oh really? Then it's case closed; you are wrong:

24.2.1
5 Just as a regular /pointer to an array/ guarantees that there
is a pointer value pointing past the last element of the array,
so for any iterator type there is an iterator value that points
past the last element of a corresponding sequence.

27.7.5
...
template <class charT> unspecified get_time(struct tm* tmb, const
charT* fmt);

7 Requires: The argument tmb shall be a valid pointer to an
object of type struct tm, and the argument fmt shall be a valid
/pointer to an array/ of objects of type charT with
char_traits<charT>::length(fmt) elements.

...

template <class charT> unspecified put_time(const struct tm* tmb,
const charT* fmt);

9 Requires: The argument tmb shall be a valid pointer to an
object of type struct tm, and the argument fmt shall be a valid
/pointer to an array/ of objects of type charT with
char_traits<charT>::length(fmt) elements.

Note /pointer to an array/ verbatim exactly as Paul uses it.

KHD

 

[Paul]

[snip]

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.

If you use the term "instruction pointer", you are using a term that
does not occur in the C++ standard. The C++ standard defines the C++
programming language. Part of that definition is the results of
operators, include operators on pointers.

No you don't get it. Anyone can use the term "pointer" in any context.
It does not have to be used in the same context as the C++ standard.
The C++ standard defines the term pointer, in the C++ langauge, where it is
in italics.
If the C++ standard were to use the term instruction pointer where "pointer"
was not in italics it does not mean this is another definition of the term
pointer.

[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.

pT1 and pT2 don't point to exactly the same type of thing. pT1
points to a T, the first sub-object in the array of 101 T dynamically
allocated by new T[101]. pT2 points to an array of 101 T. A T is
not the same as an array of 101 T.

Nonsense pT1 points to an array of 101 ints , not just one single int.
And the following code proves this:

int offset = 77;
int x = *(pT1 + offset);
If pT1 pointed to only one single object this would cause a memory accesss
error but it doesn't because pT1 does point to 101 int objects.


Additionally if pT1 didn't point to the, lets say surplus, 100 in objects
then these are not aliased therefore why can't we refer to them with an
unrelated pointer without breaking strict aliasing rules?

T (*pT3)[101] = pT1;

Only you are daft enough to assume this is possible without a cast.

There nothing daft about understanding that pT1 cannot be assigned
to pT3 because pT1, a pointer to T, is not a pointer to an array of
T, which is what pT3 is.

pT1 cannot be assigned to pT3 even if they were both null.
Its because they are different pointer types, not because of what they point
to.

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.

I'm not disagreeing with

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

You are disagreeing with this, you keep repeating that pT1 points to only
one single int , which is obvioulsy in direct disagreement with the C++
standard which clearly implies that pT1 can point to objects(plural).
..

Each is a pointers to objects in the sense that at different times
during the execution of a program each may validly point to different
objects of type T and T[101], respectively. At a given time, each
may validly point to a single object of type T and T[101],
respectively. At a given time, each does not point to multiple
objects.

With the expression:
*(pT1 + offset);
pT1 is a pointer to the beginning of the array, not just one element. The
offset is the pointer to each single element.
pT1 points to integer objects, not just one single integer object, whether
it's simultaneously or not.

In the example given, pT1 and pT2 do not have the same value; they
are initialized with separate new expressions. It is possible to
have both pT1 and pT2 refer to the same storage location. However,
even then both pointers would not have the same value because C++
pointers are typed and pT1 and pT2 have different types; C++
compilers reject the expression

pT1 == pT2

because pT1 and pT2 have different types.

As I said before only you are daft enough to not realise that the pointers
have a different type. The fact that you cannot assign one to the other,
without a cast, does not prove what they do or do not point to.

It defines what the result of dereferencing a pointer is. What
happens when you dereference, or do another operation on, a pointer
is part of what a pointer is in C++.

And what is the result of the following derefernece?

*(p + offset);

Dereference a pointer expression and you access the array of integer
objects, because the pointer points to an array of int objects.

[snip]

Well the C++ standard and Bjarne Stroustrup are both techincally
incorrect
in your opinion.

No, that is not my opinion. What I wrote was: "The many programmers
who refer to pT1 as a pointer to an array are technically incorrect."
I did not write that the C++ standard and Bjarne Stroustrup are both
technically incorrect.

Well clearly the C++ standard states that pointer of type T can point to T
objects(plural).
And clearly BS thinks that a char* can point to an array of chars.

Your argument is in direct opposition to these opinions..

Exactly does C++ standard or Bjarne Stroustrup, when he writes
about the details, state that in the statement

T a[3], *p = a;

where T is a type, that p is a pointer to an array, rather than a
pointer to the first element of an array?

Later in this post is a quote from The C++ Programming Language by
Bjarne Stroustrup that I included in a previous post. Here is part
of the quote

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)

Note: the result of the name of an array as an expression is a
pointer to the initial element of the array, not a pointer to the
array.

Where does your quote start and end?
Is the above Note added by you or is that part of the quote from BS?

I never stated that they are not technically incorrect. What I wrote
was: "The many programmers who refer to pT1 as a pointer to an array
are technically incorrect."

I understand the English language properly enough to understand the
"are not technically incorrect" and "are technically incorrect" have
opposite meanings.

But you don't understand that objects(plural) means more than one object,
which is not the same as one single object.

You omitted the rest of that glossary entry, which is: "Typically
assumed to point to a C-style string. Prefer a standard library
string over a C-style string when you can. TC++PL 2.3.3, 13.5.2."

But that makes no difference to what he has stated. The important part which
I have quoted is terminated with a full stop and it is a complete statement
in itself.
You disagree with this statement and you disagree with Bjarne.

The context of the glossary entry is about a C-style string. With a
C-style string the char* points to the first character of a zero
termainate array of characters. The glossary does not have a similar
entry for any other pointer type or for an array of objects in
general.

Are you saying that a char* can or cannot point to an array of char objects?
Now you seem to be of the opinion that its ok for char* to point to an array
of chars but no other types is that it?
You don't seem to know what you are talking about now and have no clarity in
your words.

Are you now trying to twist and manipulate context and meaning of words to
wangle out of what seems to be you in direct disagreement with BS?

Instead of immediately replying with a partial quote of a glossary
entry, you should read the example from The C++ Programming Language
that I gave (it follows).

The quote from the glossary is in complete agreement with the C++ standards
definition , and it is in complete agree with me.
It is in complete disagreement with you. Can you explain why you refuse to
accept the facts presented?

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;

[snip]

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.

What I am is someone who can discuss C++ without calling someone else
"a fuckin idiot".

And you have a problem with the term "fucking idiot"?

At any given time during the execution of a program, p may validly
point to one int object. At different times p may validly point to
different objects.

Sorry the standard disagrees, the standard states that a pointer can point
to objects(plural).
And Bjarne Stroustrup disagrees too.

Taking the use of italics in the C++ standard as indicating the
definition of a term, the term "point to" is defined (is in italics
in the C++ standard) in the following sentence from paragraph 3 of
3.9.2 (Compound types):

If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that
object, regardless of how the value was obtained.

Note that it "is said to point to that object" (singular).


It says "objects" because during the execution of a program a pointer
may point to different objects. At any one time a pointer may point
to a single object. The following sentence occurs later in the same
paragraph.

No the pointer can point to objects(plural). It doesn't matter about fucking
time the standard does not mention time.
You say "at any one time a pointer may point to a single object" but you are
speaking nonsense.

If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that
object, regardless of how the value was obtained.

Note that it "is said to point to that object" (singular). In the
C++ standard the term "point to" in that sentence is in italics,
making the sentence the definition of that term.

This obviously assumes that the people who are reading it are intelligent
enough to understand this in conjunction with the intitial sentence:
"3 A pointer to objects of type T is referred to as a "pointer to T.""

Are you suggesting that this somehow implies that the above quote is
incorrect?
Don't be so stupid use some common sense and understand the context.
..