On generally accepted terminology for pointers and arrays

Discussion in 'C++' started by Alf P. Steinbach /Usenet, Apr 12, 2011.

  1. 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>
    Alf P. Steinbach /Usenet, Apr 12, 2011
    #1
    1. Advertising

  2. Alf P. Steinbach /Usenet

    Pavel Guest

    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
    >
    Pavel, Apr 12, 2011
    #2
    1. Advertising

  3. Alf P. Steinbach /Usenet

    Paul Guest

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:io0bnr$dph$...
    > 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. :)
    Paul, Apr 12, 2011
    #3
  4. Alf P. Steinbach /Usenet

    gwowen Guest

    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, Apr 12, 2011
    #4
  5. Alf P. Steinbach /Usenet

    gwowen Guest

    On Apr 12, 7:24 am, gwowen <> 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)
    ]
    gwowen, Apr 12, 2011
    #5
  6. Alf P. Steinbach /Usenet

    Goran Guest

    On Apr 12, 8:24 am, 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.


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

    Goran.
    Goran, Apr 12, 2011
    #6
  7. Alf P. Steinbach /Usenet

    Ian Collins Guest

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

    >
    > +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
    Ian Collins, Apr 12, 2011
    #7
  8. Alf P. Steinbach /Usenet

    cpp4ever Guest

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


    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
    cpp4ever, Apr 12, 2011
    #8
  9. Alf P. Steinbach /Usenet

    Paul Guest

    "gwowen" <> wrote in message
    news:...
    On Apr 12, 7:24 am, gwowen <> 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>
    Paul, Apr 12, 2011
    #9
  10. Alf P. Steinbach /Usenet

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > 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.
    Paul, Apr 12, 2011
    #10
  11. Alf P. Steinbach /Usenet

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 12/04/2011 05:17, Paul wrote:
    >>
    >> "Alf P. Steinbach /Usenet" <> wrote in
    >> message news:io0bnr$dph$...

    >
    > [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.
    Paul, Apr 12, 2011
    #11
  12. * 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

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Apr 12, 2011
    #12
  13. Alf P. Steinbach /Usenet

    cpp4ever Guest

    On 12/04/11 15:25, Alf P. Steinbach /Usenet wrote:
    > * 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, 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
    cpp4ever, Apr 12, 2011
    #13
  14. * cpp4ever, on 12.04.2011 17:07:
    > On 12/04/11 15:25, Alf P. Steinbach /Usenet wrote:
    >> * 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

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Apr 12, 2011
    #14
  15. Alf P. Steinbach /Usenet

    cpp4ever Guest

    On 12/04/11 16:32, Alf P. Steinbach /Usenet wrote:
    > * cpp4ever, on 12.04.2011 17:07:
    >> On 12/04/11 15:25, Alf P. Steinbach /Usenet wrote:
    >>> * 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
    cpp4ever, Apr 12, 2011
    #15
  16. * 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

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Apr 12, 2011
    #16
  17. On Apr 11, 7:00 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > 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 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.
    Joshua Maurice, Apr 12, 2011
    #17
  18. Alf P. Steinbach /Usenet

    Noah Roberts Guest

    On 4/11/2011 7:00 PM, 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.


    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.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Apr 12, 2011
    #18
  19. Alf P. Steinbach /Usenet

    cpp4ever Guest

    On 12/04/11 17:16, Alf P. Steinbach /Usenet wrote:
    > * 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
    >


    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
    cpp4ever, Apr 12, 2011
    #19
  20. Alf P. Steinbach /Usenet

    Paul Guest

    "cpp4ever" <> wrote in message
    news:NvUop.27147$2...
    > 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).

    >
    > 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>
    Paul, Apr 12, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marko Vrbanec

    Generally about HTML

    Marko Vrbanec, May 29, 2005, in forum: HTML
    Replies:
    1
    Views:
    389
    David Dorward
    May 29, 2005
  2. Richard Cavell
    Replies:
    7
    Views:
    1,849
    Andrey Tarasevich
    Mar 17, 2005
  3. SG
    Replies:
    4
    Views:
    257
    Peter Remmers
    Apr 14, 2011
  4. Ian Collins
    Replies:
    9
    Views:
    253
    Alf P. Steinbach /Usenet
    Apr 14, 2011
  5. Paul
    Replies:
    63
    Views:
    1,195
Loading...

Share This Page