Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #3440 > unrolled thread

On generally accepted terminology for pointers and arrays

Back to article view | Back to comp.lang.c++

Contents

  On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 04:00 +0200
    Re: On generally accepted terminology for pointers and arrays Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2011-04-12 00:13 -0400
    Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 05:17 +0100
      Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:02 +0100
        Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:10 +0100
          Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:49 +0100
        Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 10:05 -0400
    Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 01:11 -0400
    Re: On generally accepted terminology for pointers and arrays gwowen <gwowen@gmail.com> - 2011-04-11 23:24 -0700
      Re: On generally accepted terminology for pointers and arrays gwowen <gwowen@gmail.com> - 2011-04-12 00:16 -0700
        Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 13:53 +0100
          Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:08 +0100
        Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:05 +0100
          Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:48 +0100
            Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-13 07:53 +1200
        Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 22:14 +0200
          Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-12 15:39 -0700
      Re: On generally accepted terminology for pointers and arrays Goran <goran.pusic@gmail.com> - 2011-04-12 01:39 -0700
        Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-12 20:51 +1200
      Re: On generally accepted terminology for pointers and arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-04-12 21:51 +0000
    Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 09:59 +0100
      Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 16:25 +0200
        Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 16:07 +0100
          Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 17:32 +0200
            Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 16:53 +0100
              Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 18:16 +0200
                Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 17:39 +0100
                  Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 19:32 +0200
                    Re: DILLIGAF cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 19:05 +0100
                      Re: DILLIGAF Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:36 +0200
                        Re: DILLIGAF cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 20:47 +0100
                        Re: DILLIGAF gwowen <gwowen@gmail.com> - 2011-04-12 14:48 -0700
                          Re: DILLIGAF Öö Tiib <ootiib@hot.ee> - 2011-04-12 15:16 -0700
      Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 17:48 +0100
    Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 09:37 -0700
      Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 18:34 +0100
      Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 19:38 +0200
        Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:00 -0700
          Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 20:03 +0200
            Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:06 -0700
              Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:26 +0200
                Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:33 -0700
                  Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:55 +0200
                    Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 20:14 +0100
                    Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 12:47 -0700
                      Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 22:40 +0200
        Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 14:15 -0400
          Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 20:52 +0200
            Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 20:23 +0100
            Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 16:01 -0400
              Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 13:46 -0700
                Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-12 19:49 -0700
                  Re: On generally accepted terminology for pointers and arrays hanukas <jukka@liimatta.org> - 2011-04-13 00:06 -0700
                  Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:14 -0400
                    Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-13 07:53 -0700
                  Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 09:52 +0100
                    Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 05:20 -0400
                      Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 10:31 +0100
                        Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:04 -0400
                          Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 12:35 +0100
                            Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:41 -0400
                            Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-14 07:47 +1200
                              Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 11:44 +0100
                    Re: On generally accepted terminology for pointers and arrays "io_x" <a@b.c.invalid> - 2011-04-13 18:41 +0200
                  Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 09:35 -0700
                    Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 20:17 +0100
                Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:33 -0400
                  Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:35 -0400
              Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 01:19 +0100
                Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:01 -0400
                  Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:20 -0400
                  Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 09:56 +0100
                    Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 05:24 -0400
                      Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 10:34 +0100
                        Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:07 -0400
                          Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 12:36 +0100
                            Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:43 -0400
                              Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 13:18 +0100
                                Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 08:30 -0400
              Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-13 15:57 +0200
                Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-13 15:10 +0100
                Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 11:09 -0400
                  Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 12:04 -0400
              Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 09:56 -0700
                Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 14:11 -0400
        Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 19:29 +0100
    Re: On generally accepted terminology for pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-12 09:36 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#3440 — On generally accepted terminology for pointers and arrays

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

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [next] | [standalone]

#3446

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".
>
> 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
>
>
> Cheers & hth.,
>
> - Alf
>

[toc] | [prev] | [next] | [standalone]

#3447

"Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in 
message news:io0bnr$dph$1@dont-email.me...
> 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. :-)

[toc] | [prev] | [next] | [standalone]

#3469

On 12/04/2011 05:17, Paul wrote:
>
> "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in
> message news:io0bnr$dph$1@dont-email.me...

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

/Leigh

[toc] | [prev] | [next] | [standalone]

#3474

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:cvWdnbfx8MjU0DnQnZ2dnUVZ8kmdnZ2d@giganews.com...
> On 12/04/2011 05:17, Paul wrote:
>>
>> "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in
>> message news:io0bnr$dph$1@dont-email.me...
>
> [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.

[toc] | [prev] | [next] | [standalone]

#3478

On 12/04/2011 14:10, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:cvWdnbfx8MjU0DnQnZ2dnUVZ8kmdnZ2d@giganews.com...
>> On 12/04/2011 05:17, Paul wrote:
>>>
>>> "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in
>>> message news:io0bnr$dph$1@dont-email.me...
>>
>> [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.

You have failed to prove anyone (including me) wrong about anything so 
far in this newsgroup.  You are just one big fail troll.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3480

On Tue, 12 Apr 2011 14:02:02 +0100, Leigh Johnston <leigh@i42.co.uk> wrote:

>On 12/04/2011 05:17, Paul wrote:
>>
>> "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in
>> message news:io0bnr$dph$1@dont-email.me...
>
>[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.
>
>/Leigh

Ironically, Paul seems to think that because one single person out of a great
many has illustrated a case that is a view that is similar to his, that there is
some "ounce of sense" in this person for this reason.  In fact, Paul is probably
so elated that he has forgone the conclusion that the first case in Alf's list
directly contradicts an entire discussion thread of Paul's arguments.  Of which,
of course, Paul continues to argue.

I wonder if Paul has even bothered to wonder who the "Fractally Wrong" post was
about or who was the one that won the honors of being in Alf's killfile?  Not
that I know for sure myself or truly care for that matter, but it is certainly
amusing to think that Paul is more than likely calling a person sensible who may
think that he is "Fractally Wrong",  not worth listening to, but definitely
disagrees with in the first case in his list.

As far as the subjectivity of Alf's opinion regarding case 3 in his list, if
there was no surrounding argument or debate regarding confusion between pointers
and arrays and the root posting was simply a question asking, can it be said
that in this case that this int* points to an array, I don't think a single
person would have persued the case vehemently.  There is surrounding debate
though and notable confusion on Paul's part.  The bottom line is that a great
deal of Paul's false assertions were based on the premise that an int* points to
an array far beyond the "dynamic" scope that Alf was referring to.   It even led
Paul down a path of misquoting the Standard nearly 20 times with regards to
rules for dereferencing a multidimensional array in the context of a
1-dimensional array debate.  It also resulted in a whole other thread where Paul
was casting the return of new and asking for a deallocation solution to which
there was none guaranteed by the Standard, but rather left the door wide open to
UB. 

Even something as seemingly insignificant as saying "This pointer points to an
array "right now" even though it is "not an object of pointer to array" type"
can be irresponsible and misleading, _especially_ when the topic of discussion
is a debate or basic confusion over what an array is, what a pointer is, or what
points to what.

Learning to program in C and C++ for a beginner can be daunting enough,
especially when one gets to the topic of pointers and arrays for the first time.

It is for this reason I feel strongly that technical correctness is definitely
important and it is hardly lawyeresque when one chooses the path of greater
precision when it is warranted.

A good educator will never side with ambiguity or imprecise terminology,
especially when each concept forms the basis for new, more complex concepts.

Charles

[toc] | [prev] | [next] | [standalone]

#3448

On Tue, 12 Apr 2011 04:00:24 +0200, "Alf P. Steinbach /Usenet"
<alf.p.steinbach+usenet@gmail.com> 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".
>
>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.

With regards to your third case.  

There is no harm with "right now it points to an array" if both sides of the
discussion are aware of the statement as being in its "dynamic sense" as you put
it. If all party's agree on what is being pointed to then there is no ambiguity
or technical incorrectness.   

But to imply that there could be no discussion with a context that requires more
technical precision with regards to exactly what the pointer points to is, with
all due respect, is irresponsible.  I say this because more than one of these
troll-like threads were given birth by the very nature of the first case in your
list which led to the third case.  No doubt that is why you included all three
scenarios.

At the expense of perpetuating the troll-like debate, and with the utmost
respect to you, I humbly point out three widely recognized sources that are
written explicitly in a way that you claim that you have never read.  I hardly
find any of these sets of verbiage to be lawyeresque, but rather they are simple
choices of verbiage used to merely to give technically accurate description.

1) The C++ Programming Language, Bjarne Stroustrup
section 5.3 Pointers into Arrays

While the title of the section itself makes a choice that is the subtle
disctinction between "pointer to" to "pointer into", The 2nd sentence is written
exactly, "The name of an array can be used as a pointer to its initial element."

And the supporting example is as follows.
int v[] = { 1,2,3,4};
int* p1 = v; // pointer to initial element (implicit conversion)

2) Accelerated C++, Andrew Koenig
10.1.3 Arrays (last paragraph, second sentence)

"Whenever we use the name of an array as a value, that name represents a pointer
to the initial element of the array."

3) ISO/IEC 14882
5.3.4 New (paragraph 1, last two senctences)

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


For years I have read your posts on this group, Alf.  I consider you to be an
authoritative source because I know that you have lengthy C++ programming and
discussion experience.  I do not compare myself to you in any of these regards.
I do, however, disagree with your opinion in the third case.  I do so because
you neglect to give any weight to how a discussion's context might rightfully
require more well-defined technical specificity or correctness.

Charles



>
>
>Cheers & hth.,
>
>- Alf

[toc] | [prev] | [next] | [standalone]

#3450

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.

[toc] | [prev] | [next] | [standalone]

#3451

On Apr 12, 7:24 am, gwowen <gwo...@gmail.com> wrote:

[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)
]

[toc] | [prev] | [next] | [standalone]

#3468

On 12/04/2011 08:16, gwowen wrote:
>
> [
>   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.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3473

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:fIydndSqj7X41jnQnZ2dnUVZ8uGdnZ2d@giganews.com...
> On 12/04/2011 08:16, gwowen wrote:
>>
>> [
>>   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. 

[toc] | [prev] | [next] | [standalone]

#3471

"gwowen" <gwowen@gmail.com> wrote in message 
news:0188c859-2681-4fad-b2bb-1cab739bdbbb@i14g2000yqe.googlegroups.com...
On Apr 12, 7:24 am, gwowen <gwo...@gmail.com> wrote:

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

[toc] | [prev] | [next] | [standalone]

#3477

On 12/04/2011 14:05, Paul wrote:
>
>
> [
> 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
>

Yes we already know that you dislike technical correctness but at least 
you have admitted it now by confirming that you cannot be bothered 
researching issues properly.

/Leigh

[toc] | [prev] | [next] | [standalone]

#3520

On 04/13/11 01:48 AM, Leigh Johnston wrote:
> On 12/04/2011 14:05, Paul wrote:
>>
>>
>> [
>> 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
>>
>
> Yes we already know that you dislike technical correctness but at least
> you have admitted it now by confirming that you cannot be bothered
> researching issues properly.

Issues such as configuring news clients...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3522

* gwowen, on 12.04.2011 09:16:
> On Apr 12, 7:24 am, gwowen<gwo...@gmail.com>  wrote:
>
> [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)
> ]

The "points into" is quite useful, I think not technically (because technically 
any pointing into middle of array is also a pointing to start of sub-array, 
ouch!) but it allows people some terminological & psychological elbow-room. ;-)

   * * *

Re "downcast" and "upcast", you got those directions backward wrt. common 
terminology, but I think you were aware of that possibility since you took such 
pains to describe what you meant in detail.

With conventional terminology, for single inheritance "up" is in the direction 
up the class inheritance chain, towards the top base class, and "down" is in the 
direction down the chain, towards the most specific derived class.

In the more general case we have a class derivation tree with many roots, but 
the same applies: the roots are in the direction of up.

However, it has not always been a universal convention to think of and draw such 
abstract trees with root(s) upward. Donald Knuth changed his presentation from 
first edition to second edition of "The Art of Computer Programming". So, 
somewhere there at the start of the 1970's, apparently, the notion of trees with 
roots in the air, became the common way to think of it and talk about it.

   * * *

Re the two kinds of pointers, yes it's technically a shortcoming of the C++ type 
system. But then so is the failure to distinguish pointers to automatically 
allocated objects from pointers to dynamically allocated objects. And so on. The 
various combinations of properties to distinguish explodes exponentially. I'm 
not aware of any good answer, although a RAND corporation employee (as I recall) 
once posted to clc++m a proposal to replace use of raw pointers with use of 
smart pointers that modeled these concepts/distinctions.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#3529

On Apr 12, 11:14 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * gwowen, on 12.04.2011 09:16:
> > On Apr 12, 7:24 am, gwowen<gwo...@gmail.com>  wrote:
>
> > [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)
> > ]
>
[...]
>
>    * * *
>
> Re the two kinds of pointers, yes it's technically a shortcoming of the C++ type
> system. But then so is the failure to distinguish pointers to automatically
> allocated objects from pointers to dynamically allocated objects. And so on. The
> various combinations of properties to distinguish explodes exponentially. I'm
> not aware of any good answer, although a RAND corporation employee (as I recall)
> once posted to clc++m a proposal to replace use of raw pointers with use of
> smart pointers that modeled these concepts/distinctions.

There are whole pile of smart pointers and these all already model the
sub-concepts of that i). Some are quite thin and efficient wrappers
like auto_ptr, scoped_ptr and unique_ptr. What he wanted to add?
About ii) i think that array<> and vector<> model whole arrays.
Iterators of those containers model the concept ii). Sole case when i
use array is when i have static array and want to initialize it C-
style. However C++2011 will extend ways to initialize containers so
that usage goes away as well it seems.

[toc] | [prev] | [next] | [standalone]

#3454

On Apr 12, 8:24 am, gwowen <gwo...@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#3455

On 04/12/11 08:39 PM, Goran wrote:
> On Apr 12, 8:24 am, gwowen<gwo...@gmail.com>  wrote:
>> 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.

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

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3526

On Tue, 2011-04-12, gwowen wrote:
> 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.

Excellent!  The textbooks should explain it that way. It's how I
think of pointers too (but I never managed to put it into words
like that).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web