On generally accepted terminology for pointers and arrays

[Alf P. Steinbach /Usenet]

Since my killfile works I only see one side of the numerous debates here about
pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even the
acknowledged international experts did not agree on the meaning of "pointer".
Happily the disagreements were mainly of the single kind exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling pointer
values pointers, and yet others objected to calling pointer types pointers, even
though the Holy Standard does. In case the latter is difficult to grok: I'm
talking about utterances like "it's a pointer" and "it's a car", instead of
spelling it out more literally like "it's a something of pointer type" and "it's
an object that conforms to the requirements of the 'car' type of vehicle". I
never understood the point of making such subtle distinctions, but apparently
some who are smarter and/or more knowledgable than me, do. And what about smart
pointers? If they are accepted as pointers, then a pointer needs not necessarily
be a pointer of the kind that the language supports directly. So what we have is
a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows down the
possible meanings of "pointer". Narrowing it down to the pointers directly
supported by the C++ language, the RAW POINTERS of C++, there is almost no
ambiguity. In this very limited context the term is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very much the
same for pointers and arrays. But the crucial thing is not how operationally
similar they are. Instead, the crucial thing is how they differ, for example
that an array can occupy an arbitrary amount of storage, while the size of a
pointer -- e.g. as reported by the sizeof operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the pointer is
of type "pointer to array" and points to some array (or else is null), like

int a[42];
int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because p1 is
very very strictly a pointer to an array *of a given size*. You would not be
able to e.g. "++" increment the pointer if the pointee type was of some unknown
size. And although you can have pointers to incomplete types (types of unknown
size (uh, I mean, types whose instances are of unknown size (or, more
pedantically, types whose instances, if they could exist, would be of unknown
size (hm, ok, I direct you to the Holy Standard for absolute precision)))), in
this specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an array, *and*
that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer to
question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to array, but
pointer to ElementType. It's only the dynamic situation that right after the
above declaration, p2 points to array a. Still, this is the most common
situation (the p1 thing is extremely rare!), and it would be silly to talk about
"points, at this point in the program execution, to the first element of an
array", sort of like a lawyer, instead of just saying "points to an array".

So, the answer to question (3) is also YES.

Summing up:

1) A pointer is not an array. An array is not a pointer. They can be
differentiated in many ways (e.g. sizeof, typeid, template tricks,
not to mention formal arguments of reference type).

2) A pointer can, however, point to an array.

3) And a pointer of type T* be said to point to an array of T, but only
in the dynamic sense, like "right now it points to an array".

I've seen that some people think (3) is just metaphorical. That to be
technically correct one would need to insert lawyeresque verbiage like "first
element of". That seems silly to me, and except for the trolling-threads here
I've never heard anyone speaking that way, or read anyone writing that way.


Cheers & hth.,

- Alf

 

[Pavel]

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation that
right after the above declaration, p2 points to array a. Still, this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".

So, the answer to question (3) is also YES.

Summing up:

1) A pointer is not an array. An array is not a pointer. They can be
differentiated in many ways (e.g. sizeof, typeid, template tricks,
not to mention formal arguments of reference type).

2) A pointer can, however, point to an array.

3) And a pointer of type T* be said to point to an array of T, but only
in the dynamic sense, like "right now it points to an array".

I've seen that some people think (3) is just metaphorical. That to be
technically correct one would need to insert lawyeresque verbiage like
"first element of". That seems silly to me, and except for the
trolling-threads here I've never heard anyone speaking that way, or read
anyone writing that way.

Interesting.. I often write things like &arr[0] (mainly for documentation
purposes; but without much thought; now that I am thinking of it, maybe I do it
because it looks same for both arrays and std::vector-s and have same meaning
for both. I would not be able to write 'ElType *etPt = vec;'). Just for the
record: I do not mean to troll.

-Pavel

 

[Paul]

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer types
pointers, even though the Holy Standard does. In case the latter is
difficult to grok: I'm talking about utterances like "it's a pointer" and
"it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows down
the possible meanings of "pointer". Narrowing it down to the pointers
directly supported by the C++ language, the RAW POINTERS of C++, there is
almost no ambiguity. In this very limited context the term is
well-defined.

What Alf doesn't mention is the obvious: Its an object that points to some
memory.
It points to whatever it's been intialised to point-to. A few examples may
be an array, an object, a function or null.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

An array type is not the same as a pointer type:
int arr_type[5];
int* pointer_type;
They are two very different things in the C++ type system but an array does
easily convert to a pointer(implictly), for example:
int foo( char* arg );
foo("An array of chars");
It could be said that the array is a pointer, within the function.
So this question depends how you look at it.

But an array, unless sized zero or one, is a contiguous sequence of
elements, a pointer is not. So strictly speaking, an array is not a
pointer.
int* array[1]; /*This array is a pointer but its silly*/

2) Can a pointer point to an array? Yes.

3) Can a pointer of type T* be said to point to an array of T? Yes.

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very much
the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else is
null), like

int a[42];
int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because p1
is very very strictly a pointer to an array *of a given size*. You would
not be able to e.g. "++" increment the pointer if the pointee type was of
some unknown size. And although you can have pointers to incomplete types
(types of unknown size (uh, I mean, types whose instances are of unknown
size (or, more pedantically, types whose instances, if they could exist,
would be of unknown size (hm, ok, I direct you to the Holy Standard for
absolute precision)))), in this specific case the language does not permit
it -- I don't know why.

So, in the case above we have a pointer variable that points to an array,
*and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer to
question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to array,
but pointer to ElementType. It's only the dynamic situation that right
after the above declaration, p2 points to array a. Still, this is the most
common situation (the p1 thing is extremely rare!), and it would be silly
to talk about "points, at this point in the program execution, to the
first element of an array", sort of like a lawyer, instead of just saying
"points to an array".

So, the answer to question (3) is also YES.

Summing up:

1) A pointer is not an array. An array is not a pointer. They can be
differentiated in many ways (e.g. sizeof, typeid, template tricks,
not to mention formal arguments of reference type).

2) A pointer can, however, point to an array.

3) And a pointer of type T* be said to point to an array of T, but only
in the dynamic sense, like "right now it points to an array".

I've seen that some people think (3) is just metaphorical. That to be
technically correct one would need to insert lawyeresque verbiage like
"first element of". That seems silly to me, and except for the
trolling-threads here I've never heard anyone speaking that way, or read
anyone writing that way.

Well perhaps there is someone with an ounce of sense in this community after
all.

 

[gwowen]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.

i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point. Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

ii) A bi-directional iterator into a contiguous collection of non-
polymorphic objects.
Subject to staying within the bounds (or just off the end) I can
increment, decrement to iterate over the collection, access members or
otherwise manipulate however I like. Using an array variable name as a
value just obtains such an iterator for the start of the array. Sadly,
you don't get the equivalent of an std::vector.end() member function.

As a useful rule of thumb: if you mix these concepts up, bad things
will often happen. If you don't everything will be fine.

 

[gwowen]

[replying to self - bad me]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.

i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point.  Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

[
other safe things :-
downcasting to a pointer-to-type-from-which-our-pointed-to-type is
derived.
upcasting to a pointer-to-more-derived-type, as long as I check for
dynamic_cast<> returning NULL
]

ii) A bi-directional iterator into a contiguous collection of non-
polymorphic objects.

[
I meant "random access iterator" not bidirectional, with the array
access ptr[n] being syntactic sugar for *(ptr+n)
]

 

[Goran]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.

i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point.  Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

ii) A bi-directional iterator into a contiguous collection of non-
polymorphic objects.
Subject to staying within the bounds (or just off the end) I can
increment, decrement to iterate over the collection, access members or
otherwise manipulate however I like. Using an array variable name as a
value just obtains such an iterator for the start of the array. Sadly,
you don't get the equivalent of an std::vector.end() member function.

As a useful rule of thumb: if you mix these concepts up, bad things
will often happen. If you don't everything will be fine.

+1 for all of that. i) is important for C++, ii) for C.

Goran.

 

[Ian Collins]

+1 for all of that. i) is important for C++, ii) for C.

ii) has an important use for C++ as well: using standard algorithms with
arrays.

 

[cpp4ever]

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

Strictly speaking the above is a pointer to the first element of an
array. The code below is an example of a pointer to an array.

int (*p3)[42] = &a;

But the confusion is understandable as the following array access using
the pointer is valid. But in this case the value of a[5] would be
altered and the pointer is actually pointing to the 4th element in the
array.

p2 += 3;
p2[2] = 7;

Whereas the following valid code would step the pointer over the whole
array, (or 42 array elements).

p3 += 1;
p3 -= 1;

Finally the following valid code shows how to use the array pointer to
access the array, (in this case a[5]).

p3[0][5] = 8;
(*p3)[5] = 9;

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation that
right after the above declaration, p2 points to array a. Still, this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".

So, the answer to question (3) is also YES.

Summing up:

1) A pointer is not an array. An array is not a pointer. They can be
differentiated in many ways (e.g. sizeof, typeid, template tricks,
not to mention formal arguments of reference type).

2) A pointer can, however, point to an array.

3) And a pointer of type T* be said to point to an array of T, but only
in the dynamic sense, like "right now it points to an array".

I've seen that some people think (3) is just metaphorical. That to be
technically correct one would need to insert lawyeresque verbiage like
"first element of". That seems silly to me, and except for the
trolling-threads here I've never heard anyone speaking that way, or read
anyone writing that way.


Cheers & hth.,

- Alf

Personally I always think of the array name as referring to the
address of the first element in the array. Naturally this means it can
be used to assign a value to a pointer.
All due respect to you Alf for trying to help clarify this area of
C/C++, and I agree that frequently the pointer is said to point to an
array, whereas it is actually to be used to dynamically access the
individual array elements.
Perhaps another way to understand this is that a pointer only ever
points to one object, whether that is an array entry, class/struct/array
object, or one of the standard types. It just so happens that pointers
can be used to dynamically access array elements which causes some
confusion.

Respect to all & hth

cpp4ever

 

[Paul]

[replying to self - bad me]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.

i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point. Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

[
other safe things :-
downcasting to a pointer-to-type-from-which-our-pointed-to-type is
derived.
upcasting to a pointer-to-more-derived-type, as long as I check for
dynamic_cast<> returning NULL
]


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
According to Leigh Johnston your idea of upcasting and downcasting is
back-to-front and wrong.

I also see casting up as casting to a more derived object, but I can see how
it can be seen the other way. I don't really remember what is the more
generally used terminology and I cant be bothered researching it for the
sake of arguing with people who will never accept any logical conclusion.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

<snip>

 

[Paul]

[
other safe things :-
downcasting to a pointer-to-type-from-which-our-pointed-to-type is
derived.
upcasting to a pointer-to-more-derived-type, as long as I check for
dynamic_cast<> returning NULL
]

Casting from base to derived is called downcasting not upcasting; and
casting from derived to base is called upcasting not downcasting.

Voila! Just as I was posting, the proven idiot makes his comment.

 

[Paul]

message news:[email protected]...

[snip Alf's troll]

Well perhaps there is someone with an ounce of sense in this community
after all.

Unfortunately not; Alf likes to troll; you are still wrong. A pointer to
an int is not a pointer to an array so it cannot point to an array but it
can point to an array element.

Technical correctness is important; Alf chose to disregared technical
correctness so he could add flames to the fire.

You are a proven idiot, see the thread "You snipped something" for
clairification.

 

[Alf P. Steinbach /Usenet]

* cpp4ever, on 12.04.2011 10:59:

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers& arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] =&a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation that
right after the above declaration, p2 points to array a. Still, this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".

Strictly speaking the above is a pointer to the first element of an
array.

Note that I put back my last paragraph above, which you elected to move quite a
bit away.

The only reason I can think of why you're paraphrasing a bit from the paragraph
that you moved away from the point where you put the paraphrase, apart from
trolling, would be to seek confirmation of correct understanding.

If so, then yes it seems that you roughly understood that.

However, the formal does not address terminology except for the formal.

And so the "strictly speaking" is, stricly speaking, noise, not a clarification
(otherwise your understanding would appear to be perfect).

The code below is an example of a pointer to an array.

int (*p3)[42] =&a;

And here you're again repeating an example, just changing a name.

Apparently you understood what that example was about.

But the confusion is understandable as the following array access using
the pointer is valid.

You have apparently (disregarding the possibility of trolling) asked for
confimation of your understanding of two points, that's OK, easy to deal with.

But you have to also tell what you are (or someone is) confused about, when you
start talking about your (or someone's) confusion.

Your readers are not telepaths, and at least I cannot guess what you're talking
about here -- the ESP circuit reports "no connection".


Cheers & hth.,

- Alf

 

[cpp4ever]

* cpp4ever, on 12.04.2011 10:59:

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers& arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates,
are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] =&a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation that
right after the above declaration, p2 points to array a. Still, this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".

Strictly speaking the above is a pointer to the first element of an
array.

Note that I put back my last paragraph above, which you elected to move
quite a bit away.

The only reason I can think of why you're paraphrasing a bit from the
paragraph that you moved away from the point where you put the
paraphrase, apart from trolling, would be to seek confirmation of
correct understanding.

If so, then yes it seems that you roughly understood that.

However, the formal does not address terminology except for the formal.

And so the "strictly speaking" is, stricly speaking, noise, not a
clarification (otherwise your understanding would appear to be perfect).

The code below is an example of a pointer to an array.

int (*p3)[42] =&a;

And here you're again repeating an example, just changing a name.

Apparently you understood what that example was about.

But the confusion is understandable as the following array access using
the pointer is valid.

You have apparently (disregarding the possibility of trolling) asked for
confimation of your understanding of two points, that's OK, easy to deal
with.

But you have to also tell what you are (or someone is) confused about,
when you start talking about your (or someone's) confusion.

Your readers are not telepaths, and at least I cannot guess what you're
talking about here -- the ESP circuit reports "no connection".


Cheers & hth.,

- Alf

Perhaps I am confused but doesn't asking imply a question, and I don't
see any question. Alf, what you appear to miss, (but I'm sure you do
actually understand), is that p2 and p3 are not the same type of
pointers, and implying as much is potentially missing my basic point
that a pointer only ever points to a single object type. With all due
respect neither you or I have been entirely successful in clarifying
this point. Lastly, if my attempt to help clarify is going to be
considered trolling, then I will be reluctant to provide any assistance
in future.

regards & hth

cpp4ever

 

[Alf P. Steinbach /Usenet]

* cpp4ever, on 12.04.2011 17:07:

* cpp4ever, on 12.04.2011 10:59:

On 12/04/11 03:00, Alf P. Steinbach /Usenet wrote:
Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers& arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates,
are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] =&a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation that
right after the above declaration, p2 points to array a. Still, this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".


Strictly speaking the above is a pointer to the first element of an
array.

Note that I put back my last paragraph above, which you elected to move
quite a bit away.

The only reason I can think of why you're paraphrasing a bit from the
paragraph that you moved away from the point where you put the
paraphrase, apart from trolling, would be to seek confirmation of
correct understanding.

If so, then yes it seems that you roughly understood that.

However, the formal does not address terminology except for the formal.

And so the "strictly speaking" is, stricly speaking, noise, not a
clarification (otherwise your understanding would appear to be perfect).

The code below is an example of a pointer to an array.

int (*p3)[42] =&a;

And here you're again repeating an example, just changing a name.

Apparently you understood what that example was about.

But the confusion is understandable as the following array access using
the pointer is valid.

You have apparently (disregarding the possibility of trolling) asked for
confimation of your understanding of two points, that's OK, easy to deal
with.

But you have to also tell what you are (or someone is) confused about,
when you start talking about your (or someone's) confusion.

Your readers are not telepaths, and at least I cannot guess what you're
talking about here -- the ESP circuit reports "no connection".


Cheers& hth.,

- Alf

Perhaps I am confused but doesn't asking imply a question, and I don't
see any question. Alf, what you appear to miss, (but I'm sure you do
actually understand), is that p2 and p3 are not the same type of
pointers

I think that's more than adequately covered by my statement immediately after
the declaration,


"In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType"


Perhaps part of the reason why you moved that paragraph very far away, and now
argue as if it didn't exist, was that you didn't see what it said?

and implying as much is potentially missing my basic point
that a pointer only ever points to a single object type.

I think I understand what you mean to say, but note that technically what you
literally say is as incorrect as it gets (starting with void*, and more).

With all due
respect neither you or I have been entirely successful in clarifying
this point. Lastly, if my attempt to help clarify is going to be
considered trolling, then I will be reluctant to provide any assistance
in future.

I guess it's nice with all this respect, heh.

But really, for any issue it is inevitable that one or more trolls will end up
in a heated discussion about that issue, and take one or more positions about it.

And one would be doing the community a disservice if one then adjusts one's own
positions to counter the troll(s). It's the same kind of fallacy as the
authority argument. Only, instead of saying "P is true because authority A
apparently implies that it is", one says "P is true because troll T apparently
implies that it isn't" -- that gives the troll(s) an extreme leverage...


Cheers & hth.,

- Alf

 

[cpp4ever]

* cpp4ever, on 12.04.2011 17:07:

* cpp4ever, on 12.04.2011 10:59:
On 12/04/11 03:00, Alf P. Steinbach /Usenet wrote:
Since my killfile works I only see one side of the numerous debates
here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers&
arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that
even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to
calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a
pointer"
and "it's a car", instead of spelling it out more literally like
"it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the
point
of making such subtle distinctions, but apparently some who are
smarter
and/or more knowledgable than me, do. And what about smart
pointers? If
they are accepted as pointers, then a pointer needs not necessarily
be a
pointer of the kind that the language supports directly. So what we
have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the
term
is well-defined.

Now, three questions that I have seen mentioned often in the debates,
are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not
how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the
sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or
else
is null), like

int a[42];
int (*p1)[42] =&a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee
type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType. It's only the dynamic situation
that
right after the above declaration, p2 points to array a. Still,
this is
the most common situation (the p1 thing is extremely rare!), and it
would be silly to talk about "points, at this point in the program
execution, to the first element of an array", sort of like a lawyer,
instead of just saying "points to an array".


Strictly speaking the above is a pointer to the first element of an
array.

Note that I put back my last paragraph above, which you elected to move
quite a bit away.

The only reason I can think of why you're paraphrasing a bit from the
paragraph that you moved away from the point where you put the
paraphrase, apart from trolling, would be to seek confirmation of
correct understanding.

If so, then yes it seems that you roughly understood that.

However, the formal does not address terminology except for the formal.

And so the "strictly speaking" is, stricly speaking, noise, not a
clarification (otherwise your understanding would appear to be perfect).


The code below is an example of a pointer to an array.

int (*p3)[42] =&a;

And here you're again repeating an example, just changing a name.

Apparently you understood what that example was about.


But the confusion is understandable as the following array access using
the pointer is valid.

You have apparently (disregarding the possibility of trolling) asked for
confimation of your understanding of two points, that's OK, easy to deal
with.

But you have to also tell what you are (or someone is) confused about,
when you start talking about your (or someone's) confusion.

Your readers are not telepaths, and at least I cannot guess what you're
talking about here -- the ESP circuit reports "no connection".


Cheers& hth.,

- Alf

Perhaps I am confused but doesn't asking imply a question, and I don't
see any question. Alf, what you appear to miss, (but I'm sure you do
actually understand), is that p2 and p3 are not the same type of
pointers

I think that's more than adequately covered by my statement immediately
after the declaration,


"In this case, however, the type of the pointer is not a pointer to
array, but pointer to ElementType"


Perhaps part of the reason why you moved that paragraph very far away,
and now argue as if it didn't exist, was that you didn't see what it said?

and implying as much is potentially missing my basic point
that a pointer only ever points to a single object type.

I think I understand what you mean to say, but note that technically
what you literally say is as incorrect as it gets (starting with void*,
and more).

With all due
respect neither you or I have been entirely successful in clarifying
this point. Lastly, if my attempt to help clarify is going to be
considered trolling, then I will be reluctant to provide any assistance
in future.

I guess it's nice with all this respect, heh.

But really, for any issue it is inevitable that one or more trolls will
end up in a heated discussion about that issue, and take one or more
positions about it.

And one would be doing the community a disservice if one then adjusts
one's own positions to counter the troll(s). It's the same kind of
fallacy as the authority argument. Only, instead of saying "P is true
because authority A apparently implies that it is", one says "P is true
because troll T apparently implies that it isn't" -- that gives the
troll(s) an extreme leverage...


Cheers & hth.,

- Alf

and that has not clarified your point any better for me, and talking
about trolls is off topic in any case.

Amen

cpp4ever

 

[Alf P. Steinbach /Usenet]

* cpp4ever, on 12.04.2011 17:53:

and that has not clarified your point any better for me

As I wrote earlier,

you have to also tell what you are (or someone is) confused about,
when you start talking about your (or someone's) confusion.

Your readers are not telepaths, and at least I cannot guess what
you're talking about here -- the ESP circuit reports "no connection".

I would love to clear up whatever the unspecified issue is.

What is it?

and talking about trolls is off topic in any case.

Of course trolling is not off-topic.

Not for this group's moderated sister group, not for an unmoderated group with a
charter, and certainly not for this unmoderated charter-less group.

For this thread: the topic that I addressed is so fundamentally trivial that it
would not be worth discussing at all, if it were not for the numerous earlier
threads.


Cheers & hth.,

- Alf

 

[Joshua Maurice]

Since my killfile works I only see one side of the numerous debates here about
pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even the
acknowledged international experts did not agree on the meaning of "pointer".
Happily the disagreements were mainly of the single kind exemplified by

    Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling pointer
values pointers, and yet others objected to calling pointer types pointers, even
though the Holy Standard does. In case the latter is difficult to grok: I'm
talking about utterances like "it's a pointer" and "it's a car", instead of
spelling it out more literally like "it's a something of pointer type" and "it's
an object that conforms to the requirements of the 'car' type of vehicle".. I
never understood the point of making such subtle distinctions, but apparently
some who are smarter and/or more knowledgable than me, do. And what aboutsmart
pointers? If they are accepted as pointers, then a pointer needs not necessarily
be a pointer of the kind that the language supports directly. So what we have is
a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows down the
possible meanings of "pointer". Narrowing it down to the pointers directly
supported by the C++ language, the RAW POINTERS of C++, there is almost no
ambiguity. In this very limited context the term is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

   1) Is an array a pointer?

   2) Can a pointer point to an array?

   3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very muchthe
same for pointers and arrays. But the crucial thing is not how operationally
similar they are. Instead, the crucial thing is how they differ, for example
that an array can occupy an arbitrary amount of storage, while the size of a
pointer  --  e.g. as reported by the sizeof operator  --  is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the pointer is
of type "pointer to array" and points to some array (or else is null), like

   int a[42];
   int (*p1)[42] = &a;  // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because p1is
very very strictly a pointer to an array *of a given size*. You would notbe
able to e.g. "++" increment the pointer if the pointee type was of some unknown
size. And although you can have pointers to incomplete types (types of unknown
size (uh, I mean, types whose instances are of unknown size (or, more
pedantically, types whose instances, if they could exist, would be of unknown
size (hm, ok, I direct you to the Holy Standard for absolute precision)))), in
this specific case the language does not permit it  --  I don't know why.

So, in the case above we have a pointer variable that points to an array,*and*
that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer to
question 3, namely

   int a[42];
   int* p2 = a;   // OK, p2 is a pointer to an array (dynamically).

In this case, however, the type of the pointer is not a pointer to array,but
pointer to ElementType. It's only the dynamic situation that right after the
above declaration, p2 points to array a. Still, this is the most common
situation (the p1 thing is extremely rare!), and it would be silly to talk about
"points, at this point in the program execution, to the first element of an
array", sort of like a lawyer, instead of just saying "points to an array".

So, the answer to question (3) is also YES.

Summing up:

   1) A pointer is not an array. An array is not a pointer. They can be
      differentiated in many ways (e.g. sizeof, typeid, template tricks,
      not to mention formal arguments of reference type).

   2) A pointer can, however, point to an array.

   3) And a pointer of type T* be said to point to an array of T, butonly
      in the dynamic sense, like "right now it points to an array".

I've seen that some people think (3) is just metaphorical. That to be
technically correct one would need to insert lawyeresque verbiage like "first
element of". That seems silly to me, and except for the trolling-threads here
I've never heard anyone speaking that way, or read anyone writing that way.

Cheers & hth.,

- Alf

Sure. I fully agree. I also remember stating a lot of this a while
back as well... lol.

 

[Noah Roberts]

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

The term "pointer" is an abstraction. It means different things in
different languages. This is why it's important to use standard
terminology, especially when trying to correct misconceptions. There's
not much point arguing with people who insist that you can't call what
the standard calls pointers, pointers. There is no sense in which they
can be said to be correct, and that is the important part of conversation.

The important parts about pointers are that you can gain them in certain
ways (like using &) and you can dereference them. Those two conceptual
operations make a pointer what it is. The type that you get when you
dereference the pointer is what it points to.

This is why it makes sense to call a smart pointer a pointer; it
implements the operations of a pointer. Anything that implements the
operations of a pointer IS a pointer.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

No. The p2 variable is a pointer to int because an int is what you get
when you dereference it.

3) And a pointer of type T* be said to point to an array of T, but only
in the dynamic sense, like "right now it points to an array".

The other important part of pointers is that when the point to elements
of an array, you can perform math on them. This fact though does not
change what type you get when you dereference the pointer. To claim
that a pointer points at anything other than what you get when you
dereference it flies in the face of the concept of "pointer". You can't
correctly claim, in any way that makes sense, that p2 points to an array
because that's NOT what you get when you dereference the pointer.

You could reasonably claim that p2 points INTO an array, but this is
quite a different statement.

 

[cpp4ever]

* cpp4ever, on 12.04.2011 17:53:

As I wrote earlier,



I would love to clear up whatever the unspecified issue is.

What is it?



Of course trolling is not off-topic.

Not for this group's moderated sister group, not for an unmoderated
group with a charter, and certainly not for this unmoderated
charter-less group.

For this thread: the topic that I addressed is so fundamentally trivial
that it would not be worth discussing at all, if it were not for the
numerous earlier threads.


Cheers & hth.,

- Alf

You failed to understand it the first time, effectively accusing me of
being a troll. I no longer have any interest in either trying to
understand your point, or make myself understood. Apparently you are the
peer reviewed expert and obviously have no need to understand such
trivialities any further.

Amen

cpp4ever

 

[Paul]

Since my killfile works I only see one side of the numerous debates here
about pointers and arrays.

But it does seem to be pretty confrontational.

So, herewith, me on the subject of how to talk about pointers & arrays.

When I wrote my (peer reviewed) pointers tutorial I discovered that even
the acknowledged international experts did not agree on the meaning of
"pointer". Happily the disagreements were mainly of the single kind
exemplified by

Hey, you can't call THAT a pointer (because I don't)!

Some objected to calling variables pointers, others objected to calling
pointer values pointers, and yet others objected to calling pointer
types pointers, even though the Holy Standard does. In case the latter
is difficult to grok: I'm talking about utterances like "it's a pointer"
and "it's a car", instead of spelling it out more literally like "it's a
something of pointer type" and "it's an object that conforms to the
requirements of the 'car' type of vehicle". I never understood the point
of making such subtle distinctions, but apparently some who are smarter
and/or more knowledgable than me, do. And what about smart pointers? If
they are accepted as pointers, then a pointer needs not necessarily be a
pointer of the kind that the language supports directly. So what we have
is a word that becomes more vague the larger the context is.

Happily, that means that as one narrows the context, one also narrows
down the possible meanings of "pointer". Narrowing it down to the
pointers directly supported by the C++ language, the RAW POINTERS of
C++, there is almost no ambiguity. In this very limited context the term
is well-defined.

Now, three questions that I have seen mentioned often in the debates, are

1) Is an array a pointer?

2) Can a pointer point to an array?

3) Can a pointer of type T* be said to point to an array of T?

Regarding question (1), is an array a pointer?, the answer is NO.

Some newbies think the answer is yes because lots of things are very
much the same for pointers and arrays. But the crucial thing is not how
operationally similar they are. Instead, the crucial thing is how they
differ, for example that an array can occupy an arbitrary amount of
storage, while the size of a pointer -- e.g. as reported by the sizeof
operator -- is pretty small.

Regarding question (2), can a pointer point to an array?

Here the answer is YES, and, /in two different ways/.

First, a pointer can point to an array in the Pascal sense, where the
pointer is of type "pointer to array" and points to some array (or else
is null), like

int a[42];
int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise).

It would be wrong to omit the "42" in the pointer declaration, because
p1 is very very strictly a pointer to an array *of a given size*. You
would not be able to e.g. "++" increment the pointer if the pointee type
was of some unknown size. And although you can have pointers to
incomplete types (types of unknown size (uh, I mean, types whose
instances are of unknown size (or, more pedantically, types whose
instances, if they could exist, would be of unknown size (hm, ok, I
direct you to the Holy Standard for absolute precision)))), in this
specific case the language does not permit it -- I don't know why.

So, in the case above we have a pointer variable that points to an
array, *and* that is of type pointer to array.

The second way in which a pointer can point to an array, is the answer
to question 3, namely

int a[42];
int* p2 = a; // OK, p2 is a pointer to an array (dynamically).

Strictly speaking the above is a pointer to the first element of an
array. The code below is an example of a pointer to an array.

Strictly speaking the above is PRIMARILY a pointer to an array. Yes it
specifically points to one element but that is just the nature of pointers
to arrays in C++.
To suggest it does not point to an array is completely incorrect.

int (*p3)[42] = &a;

You are assigning the address of a 1d array to a pointer-type generally used
for a 2d array. There is no need to do this unless creating a reference.

The standards defines this for pointers to arrays:
"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".

As dereferencing p3 yields a 1d array, this type of pointer can be a pointer
to a 2d array. And this is its most common use.

But the confusion is understandable as the following array access using
the pointer is valid. But in this case the value of a[5] would be
altered and the pointer is actually pointing to the 4th element in the
array.

The confusion is not understandable after it has been explained to someone
50 times , its compeltely idiotic IMHO.

<snip>