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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#3456

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

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

#3483

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

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

#3485

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

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

#3486

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

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

#3487

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

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

#3488

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

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

#3491

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

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

#3496

* cpp4ever, on 12.04.2011 18:39:
> 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.
>>
>
> You failed to understand it the first time, effectively accusing me of
> being a troll.

I think, if you could just clarify what your "it" is?

I would love to help.

If you could only communicate a little, like, at least hinting what you're 
talking about.


> I no longer have any interest in either trying to
> understand your point, or make myself understood.

Well, you have not yet attempted to specify the "it" that you are confused about.

Unfortunately I'm not telepathic.

You have to make *some* effort at communication.


> Apparently you are the
> peer reviewed expert and obviously have no need to understand such
> trivialities any further.

Thanks!

Also for earlier compliments.


Cheers & hth.,

- Alf

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

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

#3503 — Re: DILLIGAF

On 12/04/11 18:32, Alf P. Steinbach /Usenet wrote:
> * cpp4ever, on 12.04.2011 18:39:
>> 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.
>>>
>>
>> You failed to understand it the first time, effectively accusing me of
>> being a troll.
> 
> I think, if you could just clarify what your "it" is?
> 
> I would love to help.
> 
> If you could only communicate a little, like, at least hinting what
> you're talking about.
> 
> 
>> I no longer have any interest in either trying to
>> understand your point, or make myself understood.
> 
> Well, you have not yet attempted to specify the "it" that you are
> confused about.
> 
> Unfortunately I'm not telepathic.
> 
> You have to make *some* effort at communication.
> 
> 
>> Apparently you are the
>> peer reviewed expert and obviously have no need to understand such
>> trivialities any further.
> 
> Thanks!
> 
> Also for earlier compliments.
> 
> 
> Cheers & hth.,
> 
> - Alf
> 

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

#3510 — Re: DILLIGAF

Am 12.04.2011 20:05, schrieb cpp4ever:

[in a huff - acting like a 6 year-old]


OMG is this kindergarten?

Peter

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

#3518 — Re: DILLIGAF

On 12/04/11 19:36, Peter Remmers wrote:
> Am 12.04.2011 20:05, schrieb cpp4ever:
> 
> [in a huff - acting like a 6 year-old]
> 
> 
> OMG is this kindergarten?
> 
> Peter

Might as well be, this is just one big trolling exercise IMHO

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

#3525 — Re: DILLIGAF

On Apr 12, 7:36 pm, Peter Remmers
<p.remm...@expires-2011-04-30.arcornews.de> wrote:
> Am 12.04.2011 20:05, schrieb cpp4ever:
>
> [in a huff - acting like a 6 year-old]
>
> OMG is this kindergarten?
>
> Peter

Yes. It really really is.  It's very very sad to see (presumably)
grown up people behaving like 4 year olds.  "You're a troll!" "No,
you're a troll!" "Takes one to know one!"

One can only wonder how (if?) these people manage in real life when
anything that contradicts their worldview is treated with denial and
contempt. (I suspect "not well" which might be part of the problem.)
You'd get calmer, better constructed arguments at a debating
competition between Donald Trump and Sarah Palin moderated by Keith
Olbermann. The sheer social incompetence of (presumably) employed
programmers does go some way to explain the usability of so much
modern software. Almost nobody appears even slightly interested in
anyone's opinion but their own.

And now another thread, that started reasonably and calmly and
intelligently has degenerated into almost-painfully-unimaginative name
calling, because no-one will possibly admit that other's viewpoints
are valid. We should all be ashamed of ourselves. Personally, I'm
embarassed on all our behalf. It's pitiful.

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

#3528 — Re: DILLIGAF

On Apr 13, 12:48 am, gwowen <gwo...@gmail.com> wrote:
>
> And now another thread, that started reasonably and calmly and
> intelligently has degenerated into almost-painfully-unimaginative name
> calling, because no-one will possibly admit that other's viewpoints
> are valid. We should all be ashamed of ourselves. Personally, I'm
> embarassed on all our behalf. It's pitiful.

You should not be ashamed for others. Your post about two models of
pointers was quite good. Software developers are assumed to be capable
to read a lot and fast and to filter irrelevant stuff out. ;)

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

#3494

"cpp4ever" <n2xssvv.g02gfr12930@ntlworld.com> wrote in message 
news:NvUop.27147$rF.26993@newsfe12.ams2...
> 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> 

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

#3490

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

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

#3498

"Noah Roberts" <dont@email.me> wrote in message 
news:4da47fb0$0$25624$cc2e38e6@news.uslec.net...
> 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.
>

When dereferenced, a pointer to an array does not yeild what it points to 
but a (n-1) dimensional array.
You are obviously unaware of the part of the standard that explains 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".

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

#3499

* Noah Roberts, on 12.04.2011 18:37:
> On 4/11/2011 7:00 PM, Alf P. Steinbach /Usenet wrote:
[snip]
>
>> 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.

That's silly (see below).


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

Yes.


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

Here is one counter-example to your claim:

   int x;
   void* p = &x;

p cannot be derferenced. Hence in your view a claim that it points to/at x 
"flies in the face of the concept of pointer".

Do you now see that that's an impractical, silly view?


Cheers & hth.,

- Alf

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

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

#3501

On 4/12/2011 10:38 AM, Alf P. Steinbach /Usenet wrote:

> Do you now see that that's an impractical, silly view?

No, but I can now see that you're just trolling.

-- 
http://crazycpp.wordpress.com

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

#3502

* Noah Roberts, on 12.04.2011 20:00:
> On 4/12/2011 10:38 AM, Alf P. Steinbach /Usenet wrote:
>
>> Do you now see that that's an impractical, silly view?
>
> No, but I can now see that you're just trolling.

Goodbye, Noah.


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

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

#3504

On 4/12/2011 11:03 AM, Alf P. Steinbach /Usenet wrote:
> * Noah Roberts, on 12.04.2011 20:00:
>> On 4/12/2011 10:38 AM, Alf P. Steinbach /Usenet wrote:
>>
>>> Do you now see that that's an impractical, silly view?
>>
>> No, but I can now see that you're just trolling.
>
> Goodbye, Noah.
>
>
Exactly.

-- 
http://crazycpp.wordpress.com

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

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

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

csiph-web