Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays

Discussion in 'C++' started by Paul, Apr 17, 2011.

  1. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > Needless to say, there is significant dissension regarding when, or even
    > if, it
    > is ever preferrable to use well-defined terminology instead of loose or
    > casual
    > but generally accepted terminology regarding pointers and arrays.
    >
    > Examples such as:
    > int a[42];
    > int* p2 = a;

    a is an array.
    p2 is a pointer to the array.

    > apparently create huge debates about how to describe the above
    > expressions.


    >
    > Similar examples include expressions like:
    > int* p1 = new int[42];


    p1 is a pointer to a dynamic array.

    >
    > I gleen two cases representing the major divisions of opinion in this
    > matter and
    > I happen to not agree entirely with either.
    >
    > 1) Nobody is actually saying that the int pointers p1 and p2 do not point
    > to the
    > initial element of an array, but more than one has expressed that it is
    > silly to
    > put it that way.

    They point-to both the initial elelment of the array and also the array.

    >
    > 2) More than one has said that it is "generally acceptable" to say that
    > the
    > above expressions are both int pointers that point to arrays.


    Its a technical fact that both pointers point to arrays.

    >
    > My thoughts are:
    >
    > In any C++ discussion about pointer to T, is it really ever silly to say
    > that an
    > int* points to the initial element of an array of int when it is
    > well-defined to
    > do so?
    > No.
    >
    > It is not silly because widely recognized C++ sources say it just that
    > way.
    > 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers
    > into
    > Arrays
    > 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second
    > sentence)
    > 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences)
    >
    > In any C++ discussion about pointer to T, is what is claimed to be
    > "generally
    > acceptable" (the statement that an int* points to an array) ever truly
    > technically correct?
    > No.
    >
    > If the discussion is about "pointer to T" then it is both inaccurate and
    > irresponsible to say that an int* points to an array. Only in the most
    > casual
    > and general sense is this statement acceptable and only when the
    > discussion is
    > not about "pointer to T".


    I don't know what you are babbling on about , if a pointer points-to an
    array then it points-to an array.
    You are obviously trying to suggest it doesn't but it does.


    >
    > Does case #2 from above hold up under this pointer defintion?


    What pointer definition?
    YOU don't define pointers.


    >
    > From "The C++ Programming Language"
    > For a type T, T* is the type "pointer to T." That is, a variable of type
    > T* can
    > hold the address of an object of type T.
    > No.
    >
    > Is there any well-defined pointer definition that agrees with the
    > assertion that
    > an int* points to an array?
    > None that I am aware.
    >
    > I ask that if anybody knows of one to please feel free to add it to this
    > discussion.
    >
    > As my closing thought, I do not impose "lawyeresque verbiage" onto those
    > that
    > choose loose terminology in general discussions.

    You won't because you can't.
    You do not define the C++ language.

    > I do, however, make the very
    > important disctinction that there is a time to be "general" and a time to
    > be
    > "technically precise". For the case of a C++ discussion about "pointer to
    > T"
    > then the time is not to be general, but rather, and simply put,
    > technically
    > precise.
    >

    Yes and it is time to be precise and end your nonsensical ideas that a
    pointer to an array does not point-to an array.

    The following has been said by Bjarne Stroustrup and it is clearly stated in
    the C faq's. If you disagree with this then I think you are more likely to
    be incorrect than the source of this.
    "A char* can point to a single char or an array of chars."

    Clearly you disgree with this. Thats fine by me and I don't really care if
    you think its wrong but I am happy to accept it as correct as it agrees with
    my thoughts on pointers.
    Paul, Apr 17, 2011
    #1
    1. Advertising

  2. Paul

    Paul Guest

    Additionally:

    In C++ there are two ways of looking at an array:
    a) Array of objects.
    b) Array data type.

    When we ask the question , does the pointer point to an array? We have to be
    clear what we mean (a) or (b)?
    I think (a) is the generally accepted meaning of an array when used in this
    context. If we were meaning (b) then we would further qualify the question
    by saying... does the pointer point to an array-type.

    Many people seem confused and innacurate and they do not seem to understand
    the difference between these two terms. My opinion about pointers to arrays
    is completely based on the question being in the context of (a). I think
    it's important to acknowledge the above two differences with pointers to
    arrays.


    For example with the following:
    char arr[32] ={0}
    char* p_arr = arr; /*This is a pointer to the array*/
    char (*pp)[32] =&arr; /*This is a pointer to array-type*/
    /**********************************/
    Both pointers point to the same memory location. They are different types
    and both point to an array in different ways.
    p_arr is a direct array to pointer conversion , whereas pp is indirect.

    /*********************************/
    ++p_arr; /*Which element does it point to now?*/
    /*********************************/
    In general the pointer is a pointer to an array. If you need to be more
    specific you can specify exactly which element the pointer points to.


    Now its seems obvious that many people on this forum think that p_arr does
    not point to an array because its type is not an array-type. But this is
    obviously a completely ignorant argument that does not take into
    consideration the fact that an array is converted to a pointer to a (n-1)
    dimensional array.

    In the case of a 1dim array, it is converted to a pointer to the first
    element. The first element of the array is an object within the array so the
    pointer obviously also points to the array.
    If you have a plate of beans you cannot point at one single bean without
    also pointing at the beans.
    Paul, Apr 18, 2011
    #2
    1. Advertising

  3. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:eek:...
    > On Sun, 17 Apr 2011 22:00:52 +0100, "Paul" <> wrote:
    >
    >>
    >>"cg_chas" <> wrote in message
    >>news:...
    >>> Needless to say, there is significant dissension regarding when, or even
    >>> if, it
    >>> is ever preferrable to use well-defined terminology instead of loose or
    >>> casual
    >>> but generally accepted terminology regarding pointers and arrays.
    >>>
    >>> Examples such as:
    >>> int a[42];
    >>> int* p2 = a;

    >>a is an array.
    >>p2 is a pointer to the array.

    > as others have said, you've failed to grasp the subtle yet significant
    > difference between "is a pointer to" and "points to".
    >

    If X is a pointer to Y, then X points to Y.
    If X points to Y, then X is a pointer to Y.
    There is no difference.

    If you are trying to define the term "is a pointer to" to mean "is a pointer
    to type" or "is a pointer-type":
    Then you are innacurate because you cannot clearly state exactly what you
    mean and you try to wangle the meaning of the simple english term "is a
    pointer to".





    <snip>
    Paul, Apr 18, 2011
    #3
  4. Paul

    Ian Collins Guest

    Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    On 04/18/11 01:54 PM, Paul wrote:
    >
    > "cg_chas"<> wrote in message
    > news:eek:...
    >> On Sun, 17 Apr 2011 22:00:52 +0100, "Paul"<> wrote:
    >>
    >>>
    >>> "cg_chas"<> wrote in message
    >>> news:...
    >>>> Needless to say, there is significant dissension regarding when, or even
    >>>> if, it
    >>>> is ever preferrable to use well-defined terminology instead of loose or
    >>>> casual
    >>>> but generally accepted terminology regarding pointers and arrays.
    >>>>
    >>>> Examples such as:
    >>>> int a[42];
    >>>> int* p2 = a;
    >>> a is an array.
    >>> p2 is a pointer to the array.

    >> as others have said, you've failed to grasp the subtle yet significant
    >> difference between "is a pointer to" and "points to".
    >>

    > If X is a pointer to Y, then X points to Y.
    > If X points to Y, then X is a pointer to Y.
    > There is no difference.


    int n[1];

    void* p = n;

    What is p?

    --
    Ian Collins
    Ian Collins, Apr 18, 2011
    #4
  5. Paul

    Ian Collins Guest

    Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    On 04/18/11 01:40 PM, Paul wrote:

    > If you have a plate of beans you cannot point at one single bean without
    > also pointing at the beans.


    So you have no means of identifying an individual bean? Does that mean
    you eat with a ladle rather than a fork?

    --
    Ian Collins
    Ian Collins, Apr 18, 2011
    #5
  6. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 18.04.2011 04:26, schrieb cg_chas:
    > On Mon, 18 Apr 2011 02:54:16 +0100, "Paul"<> wrote:
    >
    >>
    >>"cg_chas"<> wrote in message
    >>news:eek:...
    >>> On Sun, 17 Apr 2011 22:00:52 +0100, "Paul"<> wrote:
    >>>
    >>>>
    >>>>"cg_chas"<> wrote in message
    >>>>news:...
    >>>>> Needless to say, there is significant dissension regarding when, or even
    >>>>> if, it
    >>>>> is ever preferrable to use well-defined terminology instead of loose or
    >>>>> casual
    >>>>> but generally accepted terminology regarding pointers and arrays.
    >>>>>
    >>>>> Examples such as:
    >>>>> int a[42];
    >>>>> int* p2 = a;
    >>>>a is an array.
    >>>>p2 is a pointer to the array.
    >>> as others have said, you've failed to grasp the subtle yet significant
    >>> difference between "is a pointer to" and "points to".
    >>>

    >>If X is a pointer to Y, then X points to Y.
    >>If X points to Y, then X is a pointer to Y.
    >>There is no difference.

    > That depends on your definition of pointer, doesn't it?

    It sure does.

    It is an understandable view, though. Who decides what's the difference
    between "points to" and "is a pointer to"? They are only different if
    you give them different meanings; else they pretty much mean the same,
    concerning the english language.
    You could also say "is a pointer to Y" just means "is one of the
    pointers that point to Y".

    Hm, I guess the better differentiation would be whether Y is a type or
    an object.

    int a[42];
    int* p2 = a;

    p2 is a pointer to int. <-- Y is a type
    p2 is a pointer to the array a. <-- Y is an object
    p2 points to int. <-- Y is a type
    p2 points to the array a. <-- Y is an object

    So you could say that all of these are ok.

    I agree, though, that it sounds better if you stick to only two of those:
    p2 is a pointer to int.
    p2 points to the array a.

    >>If you are trying to define the term "is a pointer to" to mean "is a pointer
    >>to type" or "is a pointer-type":

    > "is a pointer to" is not a term, it is an expression. You fail to understand
    > what a term is as you've used "pointing to bananas" as an analogy to a C++
    > discussion.

    I don't see the connection between "failure to understand what a term
    is" and the bananas...


    >>Then you are innacurate because you cannot clearly state exactly what you
    >>mean and you try to wangle the meaning of the simple english term "is a
    >>pointer to".

    > Again, back to pointing to bananas instead of adhering to a well-definition of a
    > C++ pointer. Ironically, your statement is why you are confused. You blur the
    > English meaning of pointer with the well-defined C++ meaning.
    >
    > A pointer is an English term.
    > A pointer is a well-defined C++ term.

    If you want to be pedantic about language, then I have to disagree -
    these are not terms.
    If you just say "A pointer is" using an article and no quotes, you refer
    to the actual pointer, which is surely not a term.
    What you mean is:
    "pointer" is an English term.
    "pointer" is a well-defined C++ term.


    > "pointing to", in C++, is an abstraction and often times it is used loosely to
    > express a pointer of a static type "points to" an object of a different type.
    >
    > Does that mean a pointer of a static type "is a pointer to" an object of a
    > different type? Absolutely not, and that is exactly what you've been saying. You
    > are still wrong as you fail to apply a consistent definition with any of your
    > statements.
    >
    > Come back when you have something new or meaningful to say. You repeat your
    > argument over and over to anybody that will respond, but what you cannot seem to
    > do is apply any consistent or meaningful logic in any of your assertions.
    >
    > Simply put, you are boring because you are ineffective and redundant.



    Peter
    Peter Remmers, Apr 18, 2011
    #6
  7. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    >>>>>>news:...
    >>>>>>> Needless to say, there is significant dissension regarding when, or
    >>>>>>> even
    >>>>>>> if, it
    >>>>>>> is ever preferrable to use well-defined terminology instead of
    >>>>>>> loose or
    >>>>>>> casual
    >>>>>>> but generally accepted terminology regarding pointers and arrays.
    >>>>>>>
    >>>>>>> Examples such as:
    >>>>>>> int a[42];
    >>>>>>> int* p2 = a;
    >>>>>>a is an array.
    >>>>>>p2 is a pointer to the array.
    >>>>> as others have said, you've failed to grasp the subtle yet
    >>>>> significant
    >>>>> difference between "is a pointer to" and "points to".
    >>>>>
    >>>>If X is a pointer to Y, then X points to Y.
    >>>>If X points to Y, then X is a pointer to Y.
    >>>>There is no difference.
    >>> That depends on your definition of pointer, doesn't it?

    >>It sure does.
    >>
    >>It is an understandable view, though. Who decides what's the difference
    >>between "points to" and "is a pointer to"? They are only different if
    >>you give them different meanings; else they pretty much mean the same,
    >>concerning the english language.
    >>You could also say "is a pointer to Y" just means "is one of the
    >>pointers that point to Y".

    > .. and my point still is that for Paul not to be wrong, more than one
    > definition
    > would need to be applied to his statements. The inconsistency itself
    > implies at
    > best, inconsistent application of English and C++ definition in a
    > technical C++
    > discussion, and at worst, somebody that does not know the difference.
    >
    > I am of the mind that Paul does not know the difference. I base this on
    > his
    > misquiting the Standard repeatedly as well as providing example that does
    > not
    > resolve the ambiguity of the two cases.
    >
    >>
    >>Hm, I guess the better differentiation would be whether Y is a type or
    >>an object.
    >>
    >>int a[42];
    >>int* p2 = a;
    >>
    >>p2 is a pointer to int. <-- Y is a type
    >>p2 is a pointer to the array a. <-- Y is an object
    >>p2 points to int. <-- Y is a type
    >>p2 points to the array a. <-- Y is an object
    >>
    >>So you could say that all of these are ok.

    > Then we will have to agree to disagree for three reasons.
    >
    > 1) Even if Y is an object, given the above, it is an object with a type.
    > In a
    > well-definition of a C++ pointer, type matters and in the above cases it
    > technically matters.
    >
    > 2) Only in the English terminology context is the int* p2 actually a
    > pointer
    > that points to an array. It is not a correct statement in a C++ context
    > because
    > int pointers hold the address for ints, not arrays of int. The Standard is
    > abundantly clear on this point and so are more than one authoritative
    > texts.
    >
    > 3) Regarding "p2 points to the array a" which is at best loosely accurate.

    How can it be loosely accurate?
    It can't be both loose yet also accurate.

    > Despite something being generally acceptable to say, the technical
    > accuracy of
    > such a statement is at best "technically imprecise".
    >

    Your english is technically imprecise.
    >>
    >>I agree, though, that it sounds better if you stick to only two of those:
    >>p2 is a pointer to int.
    >>p2 points to the array a.

    > Perhaps "sounding better" is what has been guiding many who have weighed
    > in on
    > this discussion which of course is subjective. Particularly those that
    > have
    > expressed that one way is a silly way to say it and another way is not.
    > The
    > greater point is that only the first of those two is technically precise
    > and the
    > second is a "generally acceptable" statement that is dependent on a casual
    > context for its accuracy.
    >
    >>
    >>>>If you are trying to define the term "is a pointer to" to mean "is a
    >>>>pointer
    >>>>to type" or "is a pointer-type":
    >>> "is a pointer to" is not a term, it is an expression. You fail to
    >>> understand
    >>> what a term is as you've used "pointing to bananas" as an analogy to a
    >>> C++
    >>> discussion.

    >>I don't see the connection between "failure to understand what a term
    >>is" and the bananas...

    > I do not have a link to the original reference here, but this is not
    > Paul's
    > first use of "pointing to banans" as his argument to define the term,
    > "pointer".
    > The statement goes to show that he applies and English definition to a C++
    > term.
    >>

    So where exactly is this term defined in the C++ standards?
    In one of the ANSI C drafts I can find this defnition of a pointer type:

    "Apointer type may be derived from a function type, an object type, or an
    incomplete
    type, called the referenced type. A pointer type describes an object whose
    value
    provides a reference to an entity of the referenced type. A pointer type
    derived from
    the referenced type T is sometimes called ''pointer to T''. The construction
    of a
    pointer type from a referenced type is called ''pointer type derivation''."

    An array or chars , is an entity of chars.
    The above quotation states "the pointer provides a reference to an entity of
    the referenced type." which means by this definition a pointer of type char
    can point to(reference) an array of chars.

    The term "pointer to X", "points to X" or any other deviation of this means
    it references X".

    >>
    >>>>Then you are innacurate because you cannot clearly state exactly what
    >>>>you
    >>>>mean and you try to wangle the meaning of the simple english term "is a
    >>>>pointer to".
    >>> Again, back to pointing to bananas instead of adhering to a
    >>> well-definition of a
    >>> C++ pointer. Ironically, your statement is why you are confused. You
    >>> blur the
    >>> English meaning of pointer with the well-defined C++ meaning.
    >>>
    >>> A pointer is an English term.
    >>> A pointer is a well-defined C++ term.

    >>If you want to be pedantic about language, then I have to disagree -
    >>these are not terms.

    > Which language? If you want to be pedantic, then clearly to do so requires
    > resolving the ambiguity between the two sentences that each express
    > "pointer" as
    > a term?
    >
    >>If you just say "A pointer is" using an article and no quotes, you refer
    >>to the actual pointer, which is surely not a term.
    >>What you mean is:
    >>"pointer" is an English term.
    >>"pointer" is a well-defined C++ term.

    Where is it defined? Please quote this definition of a pointer.


    > I do not find the two ("a pointer" and "pointer") to be mutually
    > exclusive. If
    > you want to be pedantic, the simple difference between "pointer" and "a
    > pointer"
    > is one asserts singular terminology and the other implies it. (English)
    >>
    >>

    > [.]
    >>
    >>
    >>Peter

    >
    > Admittedly, I am dubious that in your response where you are "being
    > pedantic"
    > that you chose to "snip" my supporting statement for what a pointer
    > actually is
    > (in C++), which is an abstraction for "a variable of type T* that can hold
    > the
    > address of an object of type T", which, of course, when applied, much of
    > your
    > argument falls apart.
    >


    Do you mean this?

    "For a type T, T* is the type "pointer to T." That is, a variable of type T*
    can
    hold the address of an object of type T."


    Where is this text from , this does not look like the definition of a
    pointer, all that say is that a pointer of type T can hold the address of an
    object of type T.
    Paul, Apr 18, 2011
    #7
  8. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 18.04.2011 14:31, schrieb cg_chas:
    > On Mon, 18 Apr 2011 10:57:55 +0200, Peter Remmers
    > <> wrote:
    >
    >>Am 18.04.2011 04:26, schrieb cg_chas:
    >>> On Mon, 18 Apr 2011 02:54:16 +0100, "Paul"<> wrote:
    >>>
    >>>>
    >>>>"cg_chas"<> wrote in message
    >>>>news:eek:...
    >>>>> On Sun, 17 Apr 2011 22:00:52 +0100, "Paul"<> wrote:
    >>>>>
    >>>>>>
    >>>>>>"cg_chas"<> wrote in message
    >>>>>>news:...
    >>>>>>> Needless to say, there is significant dissension regarding when, or even
    >>>>>>> if, it
    >>>>>>> is ever preferrable to use well-defined terminology instead of loose or
    >>>>>>> casual
    >>>>>>> but generally accepted terminology regarding pointers and arrays.
    >>>>>>>
    >>>>>>> Examples such as:
    >>>>>>> int a[42];
    >>>>>>> int* p2 = a;
    >>>>>>a is an array.
    >>>>>>p2 is a pointer to the array.
    >>>>> as others have said, you've failed to grasp the subtle yet significant
    >>>>> difference between "is a pointer to" and "points to".
    >>>>>
    >>>>If X is a pointer to Y, then X points to Y.
    >>>>If X points to Y, then X is a pointer to Y.
    >>>>There is no difference.
    >>> That depends on your definition of pointer, doesn't it?

    >>It sure does.
    >>
    >>It is an understandable view, though. Who decides what's the difference
    >>between "points to" and "is a pointer to"? They are only different if
    >>you give them different meanings; else they pretty much mean the same,
    >>concerning the english language.
    >>You could also say "is a pointer to Y" just means "is one of the
    >>pointers that point to Y".

    > .. and my point still is that for Paul not to be wrong, more than one definition
    > would need to be applied to his statements. The inconsistency itself implies at
    > best, inconsistent application of English and C++ definition in a technical C++
    > discussion, and at worst, somebody that does not know the difference.

    I agree that the problem is the overloading of the term "pointer" with
    two meanings, with the additional complication that the surrounding
    phrasing also matters and seems to be difficult to agree on.

    > I am of the mind that Paul does not know the difference. I base this on his
    > misquiting the Standard repeatedly as well as providing example that does not
    > resolve the ambiguity of the two cases.

    The difference is that "is a pointer to" is the wording used in the
    standard to define what a pointer is, while "points to" does not carry
    authoritative weight and is left to its imprecise meaning within the
    english language (or whatever language you want, I don't think it's
    specific to English).


    >>Hm, I guess the better differentiation would be whether Y is a type or
    >>an object.
    >>
    >>int a[42];
    >>int* p2 = a;
    >>
    >>p2 is a pointer to int.<-- Y is a type
    >>p2 is a pointer to the array a.<-- Y is an object
    >>p2 points to int.<-- Y is a type
    >>p2 points to the array a.<-- Y is an object
    >>
    >>So you could say that all of these are ok.

    > Then we will have to agree to disagree for three reasons.
    >
    > 1) Even if Y is an object, given the above, it is an object with a type. In a
    > well-definition of a C++ pointer, type matters and in the above cases it
    > technically matters.

    The definition, however, ignores the possibility that the pointee may
    have a type that differs from the pointer's pointed-to type.

    > 2) Only in the English terminology context is the int* p2 actually a pointer
    > that points to an array. It is not a correct statement in a C++ context because
    > int pointers hold the address for ints, not arrays of int. The Standard is
    > abundantly clear on this point and so are more than one authoritative texts.

    The standard is clear that when you dereference a T*, the result is a T.
    This is not the same as saying that a pointer must always, and can only
    ever, point to a T. I don't think the standard really does that. At
    least not the "can only" part, which would be against what is obviously
    possible to achieve with valid code. I admit it may demand the "must to"
    part, or else declare UB. But I'm not even sure it does that.

    > 3) Regarding "p2 points to the array a" which is at best loosely accurate.
    > Despite something being generally acceptable to say, the technical accuracy of
    > such a statement is at best "technically imprecise".
    >
    >>
    >>I agree, though, that it sounds better if you stick to only two of those:
    >>p2 is a pointer to int.
    >>p2 points to the array a.

    > Perhaps "sounding better" is what has been guiding many who have weighed in on
    > this discussion which of course is subjective. Particularly those that have
    > expressed that one way is a silly way to say it and another way is not. The
    > greater point is that only the first of those two is technically precise and the
    > second is a "generally acceptable" statement that is dependent on a casual
    > context for its accuracy.

    The problem is that there is an undeniable need to express the
    constellation that after an assignment, a pointer may
    logically/dynamically/"right now"/"loosely speaking"/etc. point to a
    whole array, but the standard provides no well-defined phrase that can
    be used to express this - leading to much debate. You can only appeal to
    common sense and use normal human language to try and express this. This
    works, just like any other phrase in human language, as long as both
    parties understand the intended meaning, and fails if one side insists
    on the narrowed-down meaning defined by the C++ standard.

    We already agreed on the fact that the level of formality depends on the
    discussion's context. However, when a discussion is not initially at the
    formal level, it would be wrong to jump in, make a correctional remark
    that a phrase is not technically correct, thereby pulling the level down
    to a formal level, and then claiming that, when talking at a formal
    level, technical correctness must be obeyed, dismissing everything else
    that is not well-defined.
    Note, that I do not mean to claim that this happened here in this NG...

    >>>>If you are trying to define the term "is a pointer to" to mean "is a pointer
    >>>>to type" or "is a pointer-type":
    >>> "is a pointer to" is not a term, it is an expression. You fail to understand
    >>> what a term is as you've used "pointing to bananas" as an analogy to a C++
    >>> discussion.

    >>I don't see the connection between "failure to understand what a term
    >>is" and the bananas...

    > I do not have a link to the original reference here, but this is not Paul's
    > first use of "pointing to banans" as his argument to define the term, "pointer".
    > The statement goes to show that he applies and English definition to a C++ term.

    Ignoring all technical correctness is equally wrong, of course. So it's
    only natural that a clash is preprogrammed when someone who disregards
    technical correctness and focuses on general terms encounters someone
    who does just the opposite.


    >>>>Then you are innacurate because you cannot clearly state exactly what you
    >>>>mean and you try to wangle the meaning of the simple english term "is a
    >>>>pointer to".
    >>> Again, back to pointing to bananas instead of adhering to a well-definition of a
    >>> C++ pointer. Ironically, your statement is why you are confused. You blur the
    >>> English meaning of pointer with the well-defined C++ meaning.
    >>>
    >>> A pointer is an English term.
    >>> A pointer is a well-defined C++ term.

    >>If you want to be pedantic about language, then I have to disagree -
    >>these are not terms.

    > Which language? If you want to be pedantic, then clearly to do so requires
    > resolving the ambiguity between the two sentences that each express "pointer" as
    > a term?
    >
    >>If you just say "A pointer is" using an article and no quotes, you refer
    >>to the actual pointer, which is surely not a term.
    >>What you mean is:
    >>"pointer" is an English term.
    >>"pointer" is a well-defined C++ term.

    > I do not find the two ("a pointer" and "pointer") to be mutually exclusive. If
    > you want to be pedantic, the simple difference between "pointer" and "a pointer"
    > is one asserts singular terminology and the other implies it. (English)


    The english language is not a well-defined language like C++, so...
    I can only explain my perceived difference (even though I already did that):
    Please note the difference in the use of quotes.

    1) A pointer is a well-defined C++ term.
    2) "pointer" is a well-defined C++ term.

    When you say 1), you refer to the idea behind the word "pointer". That
    thing that points, that has a type and a value.
    With 2) you refer to the english 7-letter-word "pointer".

    I say that only 2) makes sense, and 1) does not.


    >>
    >>

    > [.]
    >>
    >>
    >>Peter

    >
    > Admittedly, I am dubious that in your response where you are "being pedantic"
    > that you chose to "snip" my supporting statement for what a pointer actually is
    > (in C++), which is an abstraction for "a variable of type T* that can hold the
    > address of an object of type T", which, of course, when applied, much of your
    > argument falls apart.

    That's because you misunderstood me with regard to the english language,
    not with anything related to C++, which is what I snipped.

    >
    > Charles


    Peter
    Peter Remmers, Apr 18, 2011
    #8
  9. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 02:40:15 +0100, "Paul" <> wrote:
    >
    > [..]
    >>If you have a plate of beans you cannot point at one single bean without
    >>also pointing at the beans.

    > Once again, you blur English terminology with C++ terminology. Perhaps
    > you feel
    > that beans better asserts your case than bananas did?
    >

    The C++ language is defined in English, not is Spanish, Japanese or Latin.

    In C++ a pointer can be said to point to:
    a) an entity
    b) a type


    If a pointer points to an entity that is an array of T's, it does not point
    to all T's simultaneously.
    A computer can only address memory in distinct chunk sizes.
    So with :
    char* p = new char[256];

    If p(which addresses a char), is not a pointer to this array. What is a
    pointer to this array and what does it address? Or it is impossible to have
    a pointer to this array in your mind?
    You cannot have a special pointer that addresses the whole array
    simultaneously.

    Please explain simply and clearly, without any bullshit, why you think a
    char* cannot point to an array of chars.
    I doubt this is possible.
    Paul, Apr 18, 2011
    #9
  10. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 18/04/2011 16:54, Paul wrote:
    > [...]
    >
    >> Please explain simply and clearly, without any bullshit, why you think a
    >> char* cannot point to an array of chars.
    >> I doubt this is possible.

    >
    > A char* can point to an element of an array of chars; this is almost so
    > simple a concept that even a child could grasp it. The question therefore
    > is whether pointing to an array element is the same as pointing to an
    > array.
    > As C++ provides for pointer-to-array types it makes sense to say that if
    > the pointer is not a pointer-to-array type then it can't point to an array
    > *if* we are being formal (technically accurate).
    >


    Ah so you disagree with Bjarne Stroustrup when he says:

    "char* - pointer to a char or an array of char. "

    You think perhaps BS is techincally innacurate,, he obviosly isn't as
    experienced as you, and he most probably doesn't know near as much about C++
    as you do. So probably you are techincally accurate and BS is not.
    Paul, Apr 18, 2011
    #10
  11. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 15:00:45 +0100, "Paul" <> wrote:
    >
    >>
    >>"cg_chas" <> wrote in message

    > [..]
    >>> 3) Regarding "p2 points to the array a" which is at best loosely
    >>> accurate.

    >>How can it be loosely accurate?

    > see below.
    >
    >>It can't be both loose yet also accurate.

    > It most certainly can. It is loose because lacks technical precision. It
    > is
    > "loosely accurate" because it serves to convey a meaning that can
    > generally be
    > understood, but that is not to say that it is "technically accurate".
    >

    If it lacks techincal precision it cannot be accurate.
    Your english is slack, loose, sloppy, bollocks.


    >>> Despite something being generally acceptable to say, the technical
    >>> accuracy of
    >>> such a statement is at best "technically imprecise".
    >>>

    >>Your english is technically imprecise.

    > The meaning of my statement is clear in casual context as well as a
    > technical
    > context. Your statements OTOH are not.


    Your statements are clearly bullshit.
    >
    > [..]
    >>> The statement goes to show that he applies and English definition to a
    >>> C++
    >>> term.
    >>>>

    >>So where exactly is this term defined in the C++ standards?

    > See below.
    >
    > Regardless, one does not need any draft of any Standard to correctly say
    > that
    > "pointer" is a C++ term [0] see below.
    >
    >>In one of the ANSI C drafts I can find this defnition of a pointer type:
    >>
    >>"Apointer type may be derived from a function type, an object type, or an
    >>incomplete
    >>type, called the referenced type. A pointer type describes an object whose
    >>value
    >>provides a reference to an entity of the referenced type. A pointer type
    >>derived from
    >>the referenced type T is sometimes called ''pointer to T''. The
    >>construction
    >>of a
    >>pointer type from a referenced type is called ''pointer type
    >>derivation''."

    >
    >>
    >>An array or chars , is an entity of chars.
    >>The above quotation states "the pointer provides a reference to an entity
    >>of
    >>the referenced type." which means by this definition a pointer of type
    >>char
    >>can point to(reference) an array of chars.

    >
    >>
    >>The term "pointer to X", "points to X" or any other deviation of this
    >>means
    >>it references X".

    >
    > At least you are citing in context finally. What's it been? a month now?
    > :)
    >
    > In response, I can only cite what I consider to be an opposing definition
    > from
    > the C++ Standard as well as from the text written by one of the
    > maintainers of
    > the Standard who happens to be the original designer of C++.


    So you don't accept this definition?

    >
    > I leave it to you to choose which is actually appropriate to defer to in a
    > C++
    > discussion.
    >
    > Your POV can easily by expressed by a single sentence from the above
    > citation:
    > from ISO/IEC 9899 (C Standard) 6.2.5/20 5th paragraph: "A pointer type
    > describes
    > an object whose value provides a reference to an entity of the referenced
    > type."
    >
    > In a C++ context, the above statement "I think" is inapplicable for at
    > least
    > one, possibly two reasons.
    >
    > Breaking down the statement into three parts.
    >
    > 1) A pointer type describes an object (works under the C++ definition)
    > 2) the object's value provides a reference to an entity (may work under
    > the C++
    > definition, and certainly does not if you apply the C++ meaning to
    > reference)
    > 3) the reference to the entity is of the referenced type (does not work
    > under
    > the C++ definition)
    >

    Why does (3) not work, you provided no explanation.


    > It is a minor point of course, that in C++ there are no pointers to
    > references
    > (8.3.1/4).

    Its not a point at all, its simply you misinterpreting the term reference,
    the C standar dis boviously not talking about C++ references now is it :)



    > I realize the C use of reference is not the C++ use of reference,
    > but it does at least establish some level of language incompatibility
    > between
    > the two Standards which is why when there is a defintion of something in
    > the C++
    > Standard then it should be what is used. Only in the absense of a
    > definition
    > should C be deferred to, but again, I leave you to decide. I have no
    > expextation of convincing you of anything.


    Pile of shit, see above about the C standard using the term reference.

    >
    > The major point above is how "object's value" is defined.
    >
    > From ISO/IEC 14882 (C++ Standard) 8.3.1/1
    >
    > "In a declarationT D where D has the form:
    > * cv-qualifier-seq opt D1
    >
    > and the type of the identifier in the declarationT D1 is:
    > "derived-declarator-type-list T,"
    >
    > then the type of the identifier of D is:
    > "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >
    > The cv-qualifiers apply "to the pointer" and "not to the object pointed
    > to."
    >
    > I take the above not only to be a good working definition of "pointer to
    > T" in
    > the context of what a declarator is, but I also take the statement, "The
    > cv-qualifiers apply "to the pointer" and "not to the object pointed to.""
    > to
    > mean the same thing that Stroustrup uses in his definition below.
    >


    The above is describing cv qualifiers, its not the defintiion of a pointer.


    > "For a type T, T* is the type "pointer to T." That is, a variable of type
    > T*
    > can hold the address of an object of type T."
    >
    > which also defines well "pointer to T".
    >

    This does not define anything. You say Stroustrup said this but provide no
    refernece to the source of the quotation..
    The text explains that a pointer TYPE T* , can point to an object of type T.
    It doesn't define a pointer.

    > If T* is char*, both definitions say that a "pointer to T" is "pointer to
    > char".
    >

    And from this you deduce that it cannot also point to an array of chars. You
    then create, in your mind, some ficticious deifnition of a pointer that
    defines a pointer to T can only point to a T and nothing else.



    > and where "The cv-qualifiers apply "to the pointer" and "not to the object
    > pointed to." what is NOT being said is that char* points to an array.
    >
    >>

    > [..]
    >>Where is it defined? Please quote this definition of a pointer.

    > below and above.
    >

    You haven't shown a clear definition of a pointer, The best definition shown
    so far is the one I posted from the C standard.


    > [..]
    >>Do you mean this?
    >>
    >>"For a type T, T* is the type "pointer to T." That is, a variable of type
    >>T*
    >>can
    >>hold the address of an object of type T."

    > In fact I do.
    >
    >>Where is this text from ,

    > [0] It is the first two sentences from The C++ Programming Language 5.1
    > entitled
    > "Pointers".
    >
    >> this does not look like the definition of a pointer,

    > It sure does.


    Your quoted text does not define a pointer to T cannot point to an array of
    T's.
    If it comes from one of Bjarnes books then the following also comes from one
    of his books:

    <quote ref=http://www2.research.att.com/~bs/glossary.html>
    char* - pointer to a char or an array of char.
    </quote>

    This quote is crystal clear that a char* can point to an array of chars.

    At this point I woud usually say something like.. I rest my case... or haha
    you're defeated you idiot. .... or something like that, but knowing that you
    are a complete http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm
    I expect a defiant response that does not accept this proof.


    >
    >> all that say is that a pointer of type T can hold the address of an
    >>object of type T.

    > That is not all it says. It says first that, "For a type T, T* is the
    > type
    > "pointer to T"
    >
    > That is very much a definition.
    > It does not have all the pedantry that the definition from 8.3.1 does
    > because it
    > does not define pointers in the context of declarators, it merely defines
    > what a
    > pointer is and what they can do with regards to the address they hold.
    >

    a) Its not a defintion, its from a textbook for beginners
    b) It doesn't say a pointer to T cannot point to an array of T's, which is
    how you seem to be interpreting it.
    Paul, Apr 18, 2011
    #11
  12. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 17:49:21 +0100, "Paul" <> wrote:
    >
    >>
    >>"cg_chas" <> wrote in message
    >>news:...
    >>> On Mon, 18 Apr 2011 15:00:45 +0100, "Paul" <>
    >>> wrote:
    >>>
    >>>>
    >>>>"cg_chas" <> wrote in message

    > [..]
    >
    > I had actually gone to the trouble of responding to each of your
    > statements.
    > Then I decided why once again subscribe to an exercise in futility.
    > You simply do not read a post in its entirety before responding.
    > You fail to grasp context as a result.
    > Your repeated profanity indicates only your lack of credibility.
    > And with the exception of the C Standard citation, nothing you have said
    > was
    > new.
    >
    > So I will simply further elaborate on that C Standard citation for the
    > simple
    > fact that is was something new you have finally worked up the intellect
    > (or lack
    > thereof since it took a month) to contribute.
    >
    > Since you refuse to acknowledge not one, but two valid C++ pointer
    > definitions
    > because they are expressed in terms of "pointer to T", it only makes sense
    > to
    > point out to you that the C Standard definition that you provided does
    > exactly
    > the same thing.
    >
    > From ISO/IEC 9899 (C Standard) 6.2.5/20: "A pointer type derived from the
    > referenced type T is sometimes called ''pointer to T''."
    >
    > So to address your statement: Paul said,
    > "The text explains that a pointer TYPE T* , can point to an object of type
    > T.
    > It doesn't define a pointer."
    >
    > either makes all of the definitions invalid since they are expressed in
    > terms of
    > "pointer to T" (which actually would be BS), or it means that your
    > assertion of
    > what a definition is, is invalid. I think the latter.
    >
    > All three definitions express what a pointer is in terms of "pointer to
    > T". In
    > C++ you can find descriptions of what pointers are and how they work all
    > throughout the Standard. In places that do not define pointer, 8.3.1 is
    > where
    > pointer is referred to by the C++ Standard and defined along with
    > declarators.
    >
    > Here are two references that define a pointer in a C++ context.
    >
    > 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >
    > "In a declarationT D where D has the form:
    > * cv-qualifier-seq opt D1
    >
    > and the type of the identifier in the declarationT D1 is:
    > "derived-declarator-type-list T,"
    >
    > then the type of the identifier of D is:
    > "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >
    > The cv-qualifiers apply "to the pointer" and "not to the object pointed
    > to."
    >
    > 2) The C++ Programming Language 5.1 Pointers
    >
    > "For a type T, T* is the type "pointer to T." That is, a variable of type
    > T*
    > can hold the address of an object of type T."
    >

    ok so for a type T(char), T*(char*) is the type "pointer to T"("pointer to
    char"). That is a variable of type T*(char*) can hold the address of an
    object of type T(char).

    So with an array of chars , the pointer type that points to it must be a
    char*.
    Where is your confusion with this, its quite simple we are talking aobut an
    array entity, not an array type.
    That entity is an array of chars, not an array of char[SomeSize].


    > It is also worth noting that in "The C++ Programming Language" 5.3
    > Pointers into
    > Arrays explicitly defines an example:
    >
    > int v[] = {1,2,3,4};
    > int* p1 = v; // pointer to initial element
    >

    This statement is just being specific about which element it points to. It
    doesn't imply that p1 doesn't point to the array, which is the way you're
    misinterpreting it


    >
    > Your POV is hinged on the two C++ pointer definitions I provided as not
    > being
    > valid because they are both in terms of "pointer to T" and yet your C
    > pointer
    > definition that also is expressed in terms "pointer to T" should for some
    > reason
    > take precedence. Once again you are inconsistent with your logic, just in
    > a
    > different way this time.


    Rubbish the C++ statements are valid, its the way you misinterpret them that
    is invalid.
    Your interpretation is that they state a pointer to an array element doesn't
    also point to an array. This is obviously not the case.
    Paul, Apr 18, 2011
    #12
  13. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    >>> I had actually gone to the trouble of responding to each of your
    >>> statements.
    >>> Then I decided why once again subscribe to an exercise in futility.
    >>> You simply do not read a post in its entirety before responding.
    >>> You fail to grasp context as a result.
    >>> Your repeated profanity indicates only your lack of credibility.
    >>> And with the exception of the C Standard citation, nothing you have said
    >>> was
    >>> new.
    >>>
    >>> So I will simply further elaborate on that C Standard citation for the
    >>> simple
    >>> fact that is was something new you have finally worked up the intellect
    >>> (or lack
    >>> thereof since it took a month) to contribute.
    >>>
    >>> Since you refuse to acknowledge not one, but two valid C++ pointer
    >>> definitions
    >>> because they are expressed in terms of "pointer to T", it only makes
    >>> sense
    >>> to
    >>> point out to you that the C Standard definition that you provided does
    >>> exactly
    >>> the same thing.
    >>>
    >>> From ISO/IEC 9899 (C Standard) 6.2.5/20: "A pointer type derived from
    >>> the
    >>> referenced type T is sometimes called ''pointer to T''."
    >>>
    >>> So to address your statement: Paul said,
    >>> "The text explains that a pointer TYPE T* , can point to an object of
    >>> type
    >>> T.
    >>> It doesn't define a pointer."
    >>>
    >>> either makes all of the definitions invalid since they are expressed in
    >>> terms of
    >>> "pointer to T" (which actually would be BS), or it means that your
    >>> assertion of
    >>> what a definition is, is invalid. I think the latter.
    >>>
    >>> All three definitions express what a pointer is in terms of "pointer to
    >>> T". In
    >>> C++ you can find descriptions of what pointers are and how they work all
    >>> throughout the Standard. In places that do not define pointer, 8.3.1 is
    >>> where
    >>> pointer is referred to by the C++ Standard and defined along with
    >>> declarators.
    >>>
    >>> Here are two references that define a pointer in a C++ context.
    >>>
    >>> 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >>>
    >>> "In a declarationT D where D has the form:
    >>> * cv-qualifier-seq opt D1
    >>>
    >>> and the type of the identifier in the declarationT D1 is:
    >>> "derived-declarator-type-list T,"
    >>>
    >>> then the type of the identifier of D is:
    >>> "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >>>
    >>> The cv-qualifiers apply "to the pointer" and "not to the object pointed
    >>> to."
    >>>
    >>> 2) The C++ Programming Language 5.1 Pointers
    >>>
    >>> "For a type T, T* is the type "pointer to T." That is, a variable of
    >>> type
    >>> T*
    >>> can hold the address of an object of type T."
    >>>

    >>ok so for a type T(char), T*(char*) is the type "pointer to T"("pointer to
    >>char"). That is a variable of type T*(char*) can hold the address of an
    >>object of type T(char).
    >>
    >>So with an array of chars , the pointer type that points to it must be a
    >>char*.

    > Yes, exactly. As per both C++ definitons provided.
    >

    Sorry have you made a typo , or has your opinion suddenly changed?


    >>Where is your confusion with this, its quite simple we are talking aobut
    >>an
    >>array entity, not an array type.
    >>That entity is an array of chars, not an array of char[SomeSize].

    > There is no doubt you are "talking" about an array of chars. That has
    > never
    > been the issue.
    >
    > Even when you have said that it is ok to say that the char * "points to"
    > the
    > array of chars, while technically imprecise, the statement is generally
    > acceptable.

    Its not techincally imprecise its techincally correct.
    It just happens to be in the context of the array, as oppose to a specific
    element within the array.
    If I were to use this pointer to pass an array to a function, it would be
    technically correct to say I was passing a pointer to an array.


    >
    > But to say that a pointer of type char is a pointer to a char array, is
    > incorrect. That has been and still is my POV and I defer you to either of
    > the
    > two C++ definitions.

    There is no such thing as a pointer of type char.
    There is a pointer TO type char, which can also point to a array of chars.
    It is correct to say either given the correct context i.e:

    char c;
    char* p =&c; /*a pointer to a char*/
    p = new char[16]; /*now a pointer to an array of chars*/

    The context is very relevant, the type of the pointer does not define the
    pointed to entity..

    >
    > "Your" confusion however, despite the C++ definitions given, you cannot
    > seem to
    > accept how they apply to your case. Which of course brings us back to the
    > "is a
    > pointer to T" versus "points to" argument. Which is been beaten to death
    > IMO.
    >

    A pointer "is a pointer" that "points to", whatever it points to.

    The term "is a pointer to" can be used in different contexts i.e:
    a) p is a pointer to a class type T. (pointer to a type)
    b) p is a pointer to an array of int. (pointer to an entity)


    > Others have expressed the distinction at least as well as I have if not
    > more
    > concisely, Your case, however, is wrong because you do not acknowledge the
    > difference.
    >>

    Correct I don't acknoweldge what I consider your attempt to define the term
    "is a pointer to". It is usually clear form the context what is meant but
    generally speaking the term "X is a pointer to a Y" can be further qualified
    by "X is a pointer to a Y type" if it is unclear.


    >>
    >>> It is also worth noting that in "The C++ Programming Language" 5.3
    >>> Pointers into
    >>> Arrays explicitly defines an example:
    >>>
    >>> int v[] = {1,2,3,4};
    >>> int* p1 = v; // pointer to initial element
    >>>

    >>This statement is just being specific about which element it points to. It
    >>doesn't imply that p1 doesn't point to the array, which is the way you're
    >>misinterpreting it

    > The statement is specific and I thought it worth noting so I did.
    >
    > You can argue the interpretation of what it says till your heart is
    > content.
    > At the end of that argument, it will still say what it says and its
    > context is
    > quite appropriate.
    >>
    >>
    >>>
    >>> Your POV is hinged on the two C++ pointer definitions I provided as not
    >>> being
    >>> valid because they are both in terms of "pointer to T" and yet your C
    >>> pointer
    >>> definition that also is expressed in terms "pointer to T" should for
    >>> some
    >>> reason
    >>> take precedence. Once again you are inconsistent with your logic, just
    >>> in
    >>> a
    >>> different way this time.

    >>
    >>Rubbish the C++ statements are valid, its the way you misinterpret them
    >>that
    >>is invalid.
    >>Your interpretation is that they state a pointer to an array element
    >>doesn't
    >>also point to an array. This is obviously not the case.

    > My interpretation is that they are definitions. The real rubbish is that
    > in this
    > very discussion you said they were not.
    >
    > So which is it? Are they definitions or aren't they?
    >
    > If they are in fact definitions, then apply them and you get your answer.
    > If you feel they are not definitions, but the C Standard verion is, then
    > you are
    > simply wrong.
    >
    > THAT is my interpretation.


    The quotations you posted are defining different things, you presented them
    as if they defined the term "is a pointer to", which they do not define.

    As I said , the definition of a pointer seems to be inhereted from C. The
    C++ standard states this:
    "C + + is a general purpose programming language based on the C programming
    language as described in
    ISO/IEC 9899:1990 Programming Languages C (1.2). In addition to the
    facilities provided by C, C + + provides
    additional data types, classes, templates, exceptions, namespaces, inline
    functions, operator overloading,
    function name overloading, references, free store management operators, and
    additional library facilities."

    I looked in the C standard and I posted what I found to be the definition of
    a pointer-type.
    Note: I could not find a definition for simply a pointer.

    Your response was to oppose this.
    Paul, Apr 18, 2011
    #13
  14. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:eek:...
    > On Mon, 18 Apr 2011 22:09:18 +0100, "Paul" <> wrote:
    >
    > [..]
    >
    >>> So which is it? Are they definitions or aren't they?

    > (no answer?)
    >
    > Forget about what you think my interpretations are. Are these both C++
    > Pointer
    > definitions or aren't they?
    >
    > 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >
    > "In a declarationT D where D has the form:
    > * cv-qualifier-seq opt D1
    >
    > and the type of the identifier in the declarationT D1 is:
    > "derived-declarator-type-list T,"
    >
    > then the type of the identifier of D is:
    > "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >
    > The cv-qualifiers apply "to the pointer" and "not to the object pointed
    > to."
    >

    This seems to be defining the CV qualifier for a pointer-type.

    > 2) The C++ Programming Language 5.1 Pointers
    >
    > "For a type T, T* is the type "pointer to T." That is, a variable of type
    > T*
    > can hold the address of an object of type T."
    >

    This seems to be a extract from a textbook.

    I have given my reply about where to look for the proper definition of a
    pointer, which you seem to be ignoring.
    Paul, Apr 18, 2011
    #14
  15. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 22:36:04 +0100, "Paul" <> wrote:
    >>>
    >>>>> So which is it? Are they definitions or aren't they?
    >>> (no answer?)
    >>>
    >>> Forget about what you think my interpretations are. Are these both C++
    >>> Pointer
    >>> definitions or aren't they?
    >>>
    >>> 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >>>
    >>> "In a declarationT D where D has the form:
    >>> * cv-qualifier-seq opt D1
    >>>
    >>> and the type of the identifier in the declarationT D1 is:
    >>> "derived-declarator-type-list T,"
    >>>
    >>> then the type of the identifier of D is:
    >>> "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >>>
    >>> The cv-qualifiers apply "to the pointer" and "not to the object pointed
    >>> to."
    >>>

    >>This seems to be defining the CV qualifier for a pointer-type.
    >>
    >>> 2) The C++ Programming Language 5.1 Pointers
    >>>
    >>> "For a type T, T* is the type "pointer to T." That is, a variable of
    >>> type
    >>> T*
    >>> can hold the address of an object of type T."
    >>>

    >>This seems to be a extract from a textbook.
    >>
    >>I have given my reply about where to look for the proper definition of a
    >>pointer, which you seem to be ignoring.

    >
    > I am not ignoring you, but we are getting close to that since I am
    > requiring
    > that we set a common foundation for any further discussion. You are
    > failing to
    > come up with anything new, so this is where logic takes us. We both know
    > that
    > your reluctance to answer a simple question IS an answer in itself.
    >
    > YES or NO, are (1) and (2) from above valid C++ pointer definitions?


    I will decide whether I answer a question with a yes or no answer. Not you.
    Paul, Apr 18, 2011
    #15
  16. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 18.04.2011 23:22, schrieb cg_chas:
    > On Mon, 18 Apr 2011 22:09:18 +0100, "Paul"<> wrote:
    >
    > [..]
    >
    >>> So which is it? Are they definitions or aren't they?

    > (no answer?)
    >
    > Forget about what you think my interpretations are. Are these both C++ Pointer
    > definitions or aren't they?
    >
    > 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >
    > "In a declarationT D where D has the form:
    > * cv-qualifier-seq opt D1
    >
    > and the type of the identifier in the declarationT D1 is:
    > "derived-declarator-type-list T,"
    >
    > then the type of the identifier of D is:
    > "derived-declarator-type-list cv-qualifier-seq>>>pointer to T<<<.

    This describes C++ grammar. It tells you what you need to write in order
    to make an identifier D have a pointer type. It does not define what a
    pointer actually is.

    > The cv-qualifiers apply "to the pointer" and "not to the object pointed to."

    This defines the associativity of the cv-qualifiers, and is a purely
    grammar related definition. It does not define what a pointer actually is.

    > 2) The C++ Programming Language 5.1 Pointers
    >
    > "For a type T, T* is the type "pointer to T."

    Actually, up to here it's also just a syntax thing. Although, Syntax may
    be a needed part of a pointer definition.

    >That is, a variable of type T*
    > can hold the address of an object of type T."


    This may be the core of the definition, but in my eyes it's a poor one.
    Does "can" actually mean "must", or can it hold the address of an object
    of another type? (And we all know that it can)
    It says nothing about dereferencing, and that dereferencing actually
    interprets memory.


    Peter
    Peter Remmers, Apr 19, 2011
    #16
  17. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 18.04.2011 17:08, schrieb cg_chas:
    > On Mon, 18 Apr 2011 16:08:01 +0200, Peter Remmers
    > <> wrote:
    >
    >>Am 18.04.2011 14:31, schrieb cg_chas:
    >>> On Mon, 18 Apr 2011 10:57:55 +0200, Peter Remmers
    >>> <> wrote:
    >>>
    >>>>Am 18.04.2011 04:26, schrieb cg_chas:
    >>>>> On Mon, 18 Apr 2011 02:54:16 +0100, "Paul"<> wrote:
    >>>>>
    >>>>>>
    >>>>>>"cg_chas"<> wrote in message
    >>>>>>news:eek:...
    >>>>>>> On Sun, 17 Apr 2011 22:00:52 +0100, "Paul"<> wrote:
    >>>>>>>
    >>>>>>>>
    >>>>>>>>"cg_chas"<> wrote in message
    >>>>>>>>news:...

    >
    > [..]
    >
    >>1) A pointer is a well-defined C++ term.
    >>2) "pointer" is a well-defined C++ term.
    >>
    >>When you say 1), you refer to the idea behind the word "pointer". That
    >>thing that points, that has a type and a value.
    >>With 2) you refer to the english 7-letter-word "pointer".
    >>
    >>I say that only 2) makes sense, and 1) does not.

    > Sadly we travel down this path, but it is what it is. As English was once one of
    > my majors, I can assert all of the following to be sensible.
    >
    > term - noun or compound word used in a specific context meaning
    >
    > 1) A subject of a sentence may be a term.
    > 2) "subject" may be a term.
    >
    > 3) Used in a sentence phrased as a question using the above definition:
    >
    > Can a subject be a "noun or compound word used in a specific context meaning?"
    > Yes of course it can.
    >
    > 4) Are "nouns or compound words used in a specific contextual meaning" terms?
    > They certainly are.
    >
    > 5) "pointer" is a C++ term.
    >
    > 6) and since it is given that pointer is a C++ term.
    > In a list of terms all of which are pointer, it can sensibly be said that a
    > pointer is a C++ term.
    >
    > It is not hard to isolate a singular example and argue that "a" becomes
    > redundant when describing an already singular concept, but in a series of terms
    > it is not unsensible to include it.
    >
    > a blank is a term associated with a topic, a blank of a different meaning is a
    > term associated with a topic, a blank with yet another meaning is a term
    > associated with a topic.

    I'm sorry, but you completely lost me.
    Are you sure you're a C++ programmer, and not a lawyer? Because this is
    all lawyer speak to me... But maybe it's because english is not my first.

    Anyway, it's sad that you need to go down to such a level to argue a
    point that could have been discussed at a more human-readable level.


    I don't think it was that hard to understand what I was trying to convey.
    I'm saying that there are two levels:

    1 - the word
    2 - the idea that the word represents

    I claim that you can attach the tag "term" to level 1, but not to level 2.

    I also claim that the statement

    A pointer is a well-defined C++ term.

    speaks at level 2, and the statement

    "pointer" is a well-defined C++ term.

    speaks at level 1.

    Anyway, this is getting OT.

    Peter
    Peter Remmers, Apr 19, 2011
    #17
  18. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 19.04.2011 03:18, schrieb cg_chas:
    > On Tue, 19 Apr 2011 01:20:31 +0200, Peter Remmers
    > <> wrote:
    >
    >>Am 18.04.2011 17:08, schrieb cg_chas:
    >>> On Mon, 18 Apr 2011 16:08:01 +0200, Peter Remmers
    >>> <> wrote:
    >>>
    >>>>Am 18.04.2011 14:31, schrieb cg_chas:
    >>>>> On Mon, 18 Apr 2011 10:57:55 +0200, Peter Remmers
    >>>>> <> wrote:
    >>>>>
    >>>>>>Am 18.04.2011 04:26, schrieb cg_chas:
    >>>>>>> On Mon, 18 Apr 2011 02:54:16 +0100, "Paul"<> wrote:
    >>>>>>>
    >>>>>>>>
    >>>>>>>>"cg_chas"<> wrote in message
    >>>>>>>>news:eek:...
    >>>>>>>>> On Sun, 17 Apr 2011 22:00:52 +0100, "Paul"<> wrote:
    >>>>>>>>>
    >>>>>>>>>>
    >>>>>>>>>>"cg_chas"<> wrote in message
    >>>>>>>>>>news:...
    >>>
    >>> [..]
    >>>
    >>>>1) A pointer is a well-defined C++ term.
    >>>>2) "pointer" is a well-defined C++ term.
    >>>>
    >>>>When you say 1), you refer to the idea behind the word "pointer". That
    >>>>thing that points, that has a type and a value.
    >>>>With 2) you refer to the english 7-letter-word "pointer".
    >>>>
    >>>>I say that only 2) makes sense, and 1) does not.
    >>> Sadly we travel down this path, but it is what it is. As English was once one of
    >>> my majors, I can assert all of the following to be sensible.
    >>>
    >>> term - noun or compound word used in a specific context meaning
    >>>
    >>> 1) A subject of a sentence may be a term.
    >>> 2) "subject" may be a term.
    >>>
    >>> 3) Used in a sentence phrased as a question using the above definition:
    >>>
    >>> Can a subject be a "noun or compound word used in a specific context meaning?"
    >>> Yes of course it can.
    >>>
    >>> 4) Are "nouns or compound words used in a specific contextual meaning" terms?
    >>> They certainly are.
    >>>
    >>> 5) "pointer" is a C++ term.
    >>>
    >>> 6) and since it is given that pointer is a C++ term.
    >>> In a list of terms all of which are pointer, it can sensibly be said that a
    >>> pointer is a C++ term.
    >>>
    >>> It is not hard to isolate a singular example and argue that "a" becomes
    >>> redundant when describing an already singular concept, but in a series of terms
    >>> it is not unsensible to include it.
    >>>
    >>> a blank is a term associated with a topic, a blank of a different meaning is a
    >>> term associated with a topic, a blank with yet another meaning is a term
    >>> associated with a topic.

    >>I'm sorry, but you completely lost me.
    >>Are you sure you're a C++ programmer, and not a lawyer? Because this is
    >>all lawyer speak to me... But maybe it's because english is not my first.

    > You raised the question of English, not me. I simply followed through with some
    > meaningful logic. I am sorry if you are lost by it.

    It was not meaningful. You switched to legalese, and only a lawyer
    understands legalese.

    >>Anyway, it's sad that you need to go down to such a level to argue a
    >>point that could have been discussed at a more human-readable level.

    > It is sad that this path had to be gone down at all. To debate the semantics of
    > whether or not a "pointer" is a C++ term as opposed to "pointer" is a C++ term
    > was YOUR idea not mine.

    Well, the trigger was my feeling that you are overly pedantic and pull
    everything down to formalese. I just thought I found a spot where you
    were slacking and was trying to be sarcastic by pointing it out, but
    sadly I failed in arguing about it because I'm not enough of a lawyer to
    argue with you in legalese instead of english. My feeling has been
    overwhelmingly confirmed.


    > I could easily make the case that when people start down the path of arguing
    > mundane and unpertinent semantics that they are doing so to divert attention
    > away from a topic perspective that are not commited to or not fully aware of,

    You're right, it was OT. But your claim is wrong. I did not leave the
    other points unregarded, so this was not meant to distract.

    > but for now I will just say that your choice to argue over English was your
    > decision, not mine. After which, now I am being accused of being a lawyer and
    > not a C++ programmer.

    Yes, and I stand by my words.

    >>I don't think it was that hard to understand what I was trying to convey.
    >>I'm saying that there are two levels:
    >>
    >>1 - the word
    >>2 - the idea that the word represents
    >>
    >>I claim that you can attach the tag "term" to level 1, but not to level 2.
    >>
    >>I also claim that the statement
    >>
    >>A pointer is a well-defined C++ term.
    >>
    >>speaks at level 2, and the statement
    >>
    >>"pointer" is a well-defined C++ term.
    >>
    >>speaks at level 1.
    >>


    It's sad that you are, for the second time, unable to express your
    disagreement with my claims in plain english.

    >>Anyway, this is getting OT.

    > Was OT when you started us on the tangent that was not the topic at hand.
    > Time wasted and nothing gained. There's been alot off that around here lately.


    Case closed.

    Peter
    Peter Remmers, Apr 19, 2011
    #18
  19. Re: well-defined terminology versus generally accepted terminologyregarding pointers and arrays

    Am 19.04.2011 03:06, schrieb cg_chas:
    > On Tue, 19 Apr 2011 01:06:00 +0200, Peter Remmers
    > <> wrote:
    >
    >>Am 18.04.2011 23:22, schrieb cg_chas:
    >>> On Mon, 18 Apr 2011 22:09:18 +0100, "Paul"<> wrote:
    >>>
    >>> [..]
    >>>
    >>>>> So which is it? Are they definitions or aren't they?
    >>> (no answer?)
    >>>
    >>> Forget about what you think my interpretations are. Are these both C++ Pointer
    >>> definitions or aren't they?
    >>>
    >>> 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >>>
    >>> "In a declarationT D where D has the form:
    >>> * cv-qualifier-seq opt D1
    >>>
    >>> and the type of the identifier in the declarationT D1 is:
    >>> "derived-declarator-type-list T,"
    >>>
    >>> then the type of the identifier of D is:
    >>> "derived-declarator-type-list cv-qualifier-seq>>>pointer to T<<<.

    >>This describes C++ grammar. It tells you what you need to write in order
    >>to make an identifier D have a pointer type. It does not define what a
    >>pointer actually is.

    > It defines a pointer in terms of "pointer to T"


    If I define a language where the following

    curgle-jip a;

    is defined to mean "the type of a is "jip to a curgle"", then I have
    only defined syntax and grammar, but I did very much *not* define what a
    curgle or what a jip is. I introduced the terms, but I did not define them.

    > I see that as an inescapable fact. You do not. To that end we must agree to
    > disagree.
    >
    >>
    >>> The cv-qualifiers apply "to the pointer" and "not to the object pointed to."

    >>This defines the associativity of the cv-qualifiers, and is a purely
    >>grammar related definition. It does not define what a pointer actually is.
    >>
    >>> 2) The C++ Programming Language 5.1 Pointers
    >>>
    >>> "For a type T, T* is the type "pointer to T."

    >>Actually, up to here it's also just a syntax thing. Although, Syntax may
    >>be a needed part of a pointer definition.

    > Of course syntax is needed. A pointer is an abstraction for a kind of
    > variable.
    >>
    >>>That is, a variable of type T*
    >>> can hold the address of an object of type T."

    >>
    >>This may be the core of the definition, but in my eyes it's a poor one.

    > I assert that it is a valid definition. You can say it poor and that would be a
    > subjective statement.
    >
    >>Does "can" actually mean "must", or can it hold the address of an object
    >>of another type? (And we all know that it can)

    > can means "can hold the address of an object of type T"
    >
    >>It says nothing about dereferencing, and that dereferencing actually
    >>interprets memory.

    > This is true, this definition does not cover all aspects of pointer usage. It
    > simply defines what a pointer is in terms of "pointer to T"
    >
    >>
    >>
    >>Peter

    >
    > Charles


    Peter
    Peter Remmers, Apr 19, 2011
    #19
  20. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 23:47:38 +0100, "Paul" <> wrote:
    >
    >>
    >>"cg_chas" <> wrote in message
    >>news:...
    >>> On Mon, 18 Apr 2011 22:36:04 +0100, "Paul" <>
    >>> wrote:
    >>>>>
    >>>>>>> So which is it? Are they definitions or aren't they?
    >>>>> (no answer?)
    >>>>>
    >>>>> Forget about what you think my interpretations are. Are these both
    >>>>> C++
    >>>>> Pointer
    >>>>> definitions or aren't they?
    >>>>>
    >>>>> 1) ISO/IEC 14882:2003(E) 8.3.1 Pointers
    >>>>>
    >>>>> "In a declarationT D where D has the form:
    >>>>> * cv-qualifier-seq opt D1
    >>>>>
    >>>>> and the type of the identifier in the declarationT D1 is:
    >>>>> "derived-declarator-type-list T,"
    >>>>>
    >>>>> then the type of the identifier of D is:
    >>>>> "derived-declarator-type-list cv-qualifier-seq >>>pointer to T<<<.
    >>>>>
    >>>>> The cv-qualifiers apply "to the pointer" and "not to the object
    >>>>> pointed
    >>>>> to."
    >>>>>
    >>>>This seems to be defining the CV qualifier for a pointer-type.
    >>>>
    >>>>> 2) The C++ Programming Language 5.1 Pointers
    >>>>>
    >>>>> "For a type T, T* is the type "pointer to T." That is, a variable of
    >>>>> type
    >>>>> T*
    >>>>> can hold the address of an object of type T."
    >>>>>
    >>>>This seems to be a extract from a textbook.
    >>>>
    >>>>I have given my reply about where to look for the proper definition of a
    >>>>pointer, which you seem to be ignoring.
    >>>
    >>> I am not ignoring you, but we are getting close to that since I am
    >>> requiring
    >>> that we set a common foundation for any further discussion. You are
    >>> failing to
    >>> come up with anything new, so this is where logic takes us. We both
    >>> know
    >>> that
    >>> your reluctance to answer a simple question IS an answer in itself.
    >>>
    >>> YES or NO, are (1) and (2) from above valid C++ pointer definitions?

    >>
    >>I will decide whether I answer a question with a yes or no answer. Not
    >>you.
    >>

    > clearly. the absense of an answer is the answer.
    >

    I answered it already. You are simply repeating the same question.
    You have snipped all the relevant stuff.
    Paul, Apr 19, 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. Oodini
    Replies:
    1
    Views:
    1,767
    Keith Thompson
    Sep 27, 2005
  2. Alf P. Steinbach /Usenet
    Replies:
    61
    Views:
    1,035
  3. SG
    Replies:
    4
    Views:
    274
    Peter Remmers
    Apr 14, 2011
  4. Ian Collins
    Replies:
    9
    Views:
    272
    Alf P. Steinbach /Usenet
    Apr 14, 2011
  5. Paul Butcher
    Replies:
    12
    Views:
    708
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page