Well defined meaning of pointer to an array

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

  1. Paul

    Paul Guest

    A char* can point to a single char or an array of chars.

    char* p= new char[64];
    The above is a pointer points to an array of 64 chars.

    I have no more to say on this subject especially to idiots who do not
    understand the difference between:
    a) pointer to array objects
    b) pointer to array data type
     
    Paul, Apr 18, 2011
    #1
    1. Advertising

  2. Paul <> wrote:
    > I have no more to say on this subject


    Haha. You are quite the joker, aren't you?

    Let's count how long it takes before you make another post on this very
    same subject. Bet starts at 1 day.
     
    Juha Nieminen, Apr 18, 2011
    #2
    1. Advertising

  3. Paul

    Paul Guest

    "Paul" <> wrote in message
    news:AgTqp.23953$2...
    >A char* can point to a single char or an array of chars.
    >
    > char* p= new char[64];
    > The above is a pointer points to an array of 64 chars.
    >
    > I have no more to say on this subject especially to idiots who do not
    > understand the difference between:
    > a) pointer to array objects

    should be pointer to an array OF objects.
    > b) pointer to array data type
    >
     
    Paul, Apr 18, 2011
    #3
  4. Paul wrote:

    > A char* can point to a single char or an array of chars.
    >
    > char* p= new char[64];
    > The above is a pointer points to an array of 64 chars.
    >


    Does it?

    "If an object of type T is located at an address A, a pointer of type cv T*
    whose value is the address A is said to *point to* that object, regardless
    of how the value was obtained."

    Your use of "points to" is not covered by the text, I think. You can say
    that "p" stores or represents the address of an array of 64 chars, though.
     
    Johannes Schaub, Apr 18, 2011
    #4
  5. Paul

    Paul Guest

    "Johannes Schaub" <> wrote in message
    news:4dac2a74$0$6984$-online.net...
    > Paul wrote:
    >
    >> A char* can point to a single char or an array of chars.
    >>
    >> char* p= new char[64];
    >> The above is a pointer points to an array of 64 chars.
    >>

    >

    Firstly please excuse my typos as I just battered this out on the keyboard
    and chaged it from "above is a pointer to" to "above pointer points to".
    To avoid the repetative bullshit that "is a pointer to " does not mean the
    same as "points to".

    > Does it?
    >
    > "If an object of type T is located at an address A, a pointer of type cv
    > T*
    > whose value is the address A is said to *point to* that object, regardless
    > of how the value was obtained."
    >
    > Your use of "points to" is not covered by the text, I think.


    So why mention that text if it doesn't cover it?

    > You can say
    > that "p" stores or represents the address of an array of 64 chars, though.
    >

    I can say that p points to an array of chars.
     
    Paul, Apr 18, 2011
    #5
  6. Paul <> wrote:
    > I can say that p points to an array of chars.


    Betting ends. It took you a bit less than 4 hours to say something
    about the subject you didn't have anything else to say.
     
    Juha Nieminen, Apr 18, 2011
    #6
  7. Paul

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Mon, 18 Apr 2011 14:07:13 +0100, "Paul" <> wrote:
    >>> Paul wrote:
    >>>
    >>>> A char* can point to a single char or an array of chars.
    >>>>
    >>>> char* p= new char[64];
    >>>> The above is a pointer points to an array of 64 chars.
    >>>>
    >>>

    >>Firstly please excuse my typos as I just battered this out on the keyboard
    >>and chaged it from "above is a pointer to" to "above pointer points to".
    >>To avoid the repetative bullshit that "is a pointer to " does not mean the
    >>same as "points to".
    >>
    >>> Does it?
    >>>
    >>> "If an object of type T is located at an address A, a pointer of type cv
    >>> T*
    >>> whose value is the address A is said to *point to* that object,
    >>> regardless
    >>> of how the value was obtained."
    >>>
    >>> Your use of "points to" is not covered by the text, I think.

    >>
    >>So why mention that text if it doesn't cover it?
    >>
    >>> You can say
    >>> that "p" stores or represents the address of an array of 64 chars,
    >>> though.
    >>>

    >>I can say that p points to an array of chars.

    > You could say that Elvis lives too. Which would equally be technically
    > incorrect, but to the die hard Elvis fans, they would gladly qualify their
    > meaning that "Elvis lives on in their hearts".
    >
    > The point is that just because you can say something, does not make it
    > technically precise or even technically correct in a technical C++
    > discussion
    > that has a topic regarding well-defined.
    >

    Its not just me that is saying this , Bjarne Stroustrup says this too , and
    its in the C FAQ's.


    > So of course it is relevant when he said, "the text does not cover it".
    > Since
    > relevance in this topic should be with regards to well-defined as you
    > yourself
    > have suggested that it does.
    >
     
    Paul, Apr 18, 2011
    #7
  8. Paul

    Paul Guest

    "Juha Nieminen" <> wrote in message
    news:4dac3fe8$0$2861$...
    > Paul <> wrote:
    >> I can say that p points to an array of chars.

    >
    > Betting ends. It took you a bit less than 4 hours to say something
    > about the subject you didn't have anything else to say.
    >

    I wouldn't have bothered if I hadn't made a few typos , but now I have to
    clarify the technical correctness of the underlying argument. :)
     
    Paul, Apr 18, 2011
    #8
  9. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 18/04/2011 10:13, Paul wrote:
    >> A char* can point to a single char or an array of chars.

    >
    > Yes if being technically inaccurate and equating pointing to an array
    > element with pointing to an array.
    >
    >>
    >> char* p= new char[64];
    >> The above is a pointer points to an array of 64 chars.

    >
    > That makes no sense.
    >
    >>
    >> I have no more to say on this subject especially to idiots who do not
    >> understand the difference between:
    >> a) pointer to array objects

    >
    > That makes no sense.
    >
    >> b) pointer to array data type

    >
    > Who cares about terms *you* define?
    >

    Typical trollish behaviour, pounce on the typos and ignore the underlying
    technical argument.
     
    Paul, Apr 18, 2011
    #9
  10. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 18/04/2011 15:43, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 18/04/2011 10:13, Paul wrote:
    >>>> A char* can point to a single char or an array of chars.
    >>>
    >>> Yes if being technically inaccurate and equating pointing to an array
    >>> element with pointing to an array.
    >>>
    >>>>
    >>>> char* p= new char[64];
    >>>> The above is a pointer points to an array of 64 chars.
    >>>
    >>> That makes no sense.
    >>>
    >>>>
    >>>> I have no more to say on this subject especially to idiots who do not
    >>>> understand the difference between:
    >>>> a) pointer to array objects
    >>>
    >>> That makes no sense.
    >>>
    >>>> b) pointer to array data type
    >>>
    >>> Who cares about terms *you* define?
    >>>

    >> Typical trollish behaviour, pounce on the typos and ignore the
    >> underlying technical argument.

    >
    > Based on your past behaviour you deserve little respect. My replies are
    > technically accurate even if troll-like; trolling a troll is perfectly
    > acceptable behaviour if the trolling is also a valid correction (which
    > they are).
    >

    You are a http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm
     
    Paul, Apr 18, 2011
    #10
  11. Paul <> wrote:

    > A char* can point to a single char or an array of chars.


    No.

    > char* p= new char[64];
    > The above is a pointer points to an array of 64 chars.


    No, that's a pointer to a single char, the one at the
    very start of the array. If you want a pointer to an
    array of 64 chars you need

    char (*p64)[64];

    It's really simple: If you increment a pointer by 1 it
    always points to the address directly behind the object
    it pointed to (its value is increased by the size of the
    type of object it points to). And if you incrememt 'p'
    by 1 it points to the next char in the array, so it's a
    pointer to a single char, not an array of so many chars.
    That it points to the first element of the array doesn't
    change anything about that. But if you increment 'p64' by
    1 it points directly past the end of the array, so that's
    a pointer to an array of 64 chars.

    Perhaps you should read Chris Torek's nice article about
    pointers and arrays

    http://web.torek.net/torek/c/pa.html

    and also

    http://web.torek.net/torek/c/expr.html#therule

    (which might address the reasons behind your confusion).
    While it's about C C++ works the same way.

    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Apr 18, 2011
    #11
  12. Paul

    Paul Guest

    "Jens Thoms Toerring" <> wrote in message
    news:-berlin.de...
    > Paul <> wrote:
    >
    >> A char* can point to a single char or an array of chars.

    >
    > No.
    >

    Ah so this is wrong?

    <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    "The pointer declaration char *p, on the other hand, requests a place which
    holds a pointer, to be known by the name ``p''. This pointer can point
    almost anywhere: to any char, or to any contiguous array of chars, or
    nowhere"
    </quote>

    >> char* p= new char[64];
    >> The above is a pointer points to an array of 64 chars.

    >
    > No, that's a pointer to a single char, the one at the
    > very start of the array. If you want a pointer to an
    > array of 64 chars you need
    >
    > char (*p64)[64];
    >

    Ok so this is also wrong?
    <quote ref=http://www2.research.att.com/~bs/glossary.html>
    "char* - pointer to a char or an array of char."
    </quote>



    > It's really simple: If you increment a pointer by 1 it
    > always points to the address directly behind the object
    > it pointed to (its value is increased by the size of the
    > type of object it points to). And if you incrememt 'p'
    > by 1 it points to the next char in the array, so it's a
    > pointer to a single char, not an array of so many chars.
    > That it points to the first element of the array doesn't
    > change anything about that. But if you increment 'p64' by
    > 1 it points directly past the end of the array, so that's
    > a pointer to an array of 64 chars.
    >
    > Perhaps you should read Chris Torek's nice article about
    > pointers and arrays
    >
    > http://web.torek.net/torek/c/pa.html
    >
    > and also
    >
    > http://web.torek.net/torek/c/expr.html#therule
    >
    > (which might address the reasons behind your confusion).
    > While it's about C C++ works the same way.
    >

    Thanks for your post but I think you should read the quotes I posted above
    from Bjarbne Stroustrup and Steve Summit.
     
    Paul, Apr 18, 2011
    #12
  13. Paul

    Noah Roberts Guest

    On 2011-04-18 06:43, Juha Nieminen wrote:
    > Paul<> wrote:
    >> I can say that p points to an array of chars.

    >
    > Betting ends. It took you a bit less than 4 hours to say something
    > about the subject you didn't have anything else to say.
    >


    Technically speaking, its not a contradiction. He DOESN'T have anything
    ELSE to say. He's actually just repeating the same things he's already
    said many, many, many times already.

    Sooner or later I'm sure the deceased Equidae will reanimate and
    motivate down the highway if he (and the rest for that matter) just
    keeps hitting it with the same set of sticks.

    --
    http://crazycpp.wordpress.com
     
    Noah Roberts, Apr 18, 2011
    #13
  14. Paul <> wrote:

    > "Jens Thoms Toerring" <> wrote in message
    > news:-berlin.de...
    > > Paul <> wrote:
    > >
    > >> A char* can point to a single char or an array of chars.

    > >
    > > No.
    > >

    > Ah so this is wrong?


    > <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    > "The pointer declaration char *p, on the other hand, requests a place which
    > holds a pointer, to be known by the name ``p''. This pointer can point
    > almost anywhere: to any char, or to any contiguous array of chars, or
    > nowhere"
    > </quote>


    Sloppy speaking. What's really meant is "to the first element
    of any continuous array" (and then we could also ask "what's
    a non-continous array?"). Since a char and an array of chars
    are completely different types a pointer to char can only
    point to a char, not also at the same time to the different
    type of array of chars - only to an element of the array. But
    there are so many cases were an array (when used in value
    context) gets converted to a pointer to its first element
    that it has become common lingo to call that also "a poin-
    ter to the array" when it actually just is a pointer to the
    first element. Perhaps unfortunate, but that's life. And when
    you go to the next point in the C FAQ (6.3 instead of 6.2)

    http://c-faq.com/aryptr/aryptrequiv.html

    you will find that it then goes into greater detail, explicitly
    speaking about the "first element of an array":

    | A reference to an object of type array-of-T which appears
    | in an expression decays (with three exceptions) into a pointer
    | to its first element; the type of the resultant pointer is
    | pointer-to-T.

    The word "decays" seems to be at the heart of many misunder-
    standings: this is a conversion the compiler does under cer-
    tain circumstances but does not imply equality.

    > >> char* p= new char[64];
    > >> The above is a pointer points to an array of 64 chars.

    > >
    > > No, that's a pointer to a single char, the one at the
    > > very start of the array. If you want a pointer to an
    > > array of 64 chars you need
    > >
    > > char (*p64)[64];
    > >

    > Ok so this is also wrong?
    > <quote ref=http://www2.research.att.com/~bs/glossary.html>
    > "char* - pointer to a char or an array of char."
    > </quote>


    Again lingo, not wrong when meant in the right way, just a
    bit sloppily expressed. It might have been better if he had
    said "...or the first element of an array", but then this is
    a glossary, not an in-depth explanation.

    > > It's really simple: If you increment a pointer by 1 it
    > > always points to the address directly behind the object
    > > it pointed to (its value is increased by the size of the
    > > type of object it points to). And if you incrememt 'p'
    > > by 1 it points to the next char in the array, so it's a
    > > pointer to a single char, not an array of so many chars.
    > > That it points to the first element of the array doesn't
    > > change anything about that. But if you increment 'p64' by
    > > 1 it points directly past the end of the array, so that's
    > > a pointer to an array of 64 chars.
    > >
    > > Perhaps you should read Chris Torek's nice article about
    > > pointers and arrays
    > >
    > > http://web.torek.net/torek/c/pa.html
    > >
    > > and also
    > >
    > > http://web.torek.net/torek/c/expr.html#therule
    > >
    > > (which might address the reasons behind your confusion).
    > > While it's about C C++ works the same way.
    > >

    > Thanks for your post but I think you should read the quotes I posted above
    > from Bjarbne Stroustrup and Steve Summit.


    I did but I don't think they really support your point of view.

    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Apr 18, 2011
    #14
  15. Paul

    Paul Guest

    "Jens Thoms Toerring" <> wrote in message
    news:-berlin.de...
    > Paul <> wrote:
    >
    >> "Jens Thoms Toerring" <> wrote in message
    >> news:-berlin.de...
    >> > Paul <> wrote:
    >> >
    >> >> A char* can point to a single char or an array of chars.
    >> >
    >> > No.
    >> >

    >> Ah so this is wrong?

    >
    >> <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    >> "The pointer declaration char *p, on the other hand, requests a place
    >> which
    >> holds a pointer, to be known by the name ``p''. This pointer can point
    >> almost anywhere: to any char, or to any contiguous array of chars, or
    >> nowhere"
    >> </quote>

    >
    > Sloppy speaking. What's really meant is "to the first element
    > of any continuous array" (and then we could also ask "what's
    > a non-continous array?").

    How do you know he means pointing to the first element of an array?
    The pointer can point to any element or even to the end of the array.

    And what is a non-continuous array then? I think C++ arrays are guaranteed
    to be contiguous.


    >Since a char and an array of chars
    > are completely different types a pointer to char can only
    > point to a char, not also at the same time to the different
    > type of array of chars - only to an element of the array.


    A char within an array is the same type as a single char.
    What type of object do you think an array of chars contains, if not a char
    type?

    >But
    > there are so many cases were an array (when used in value
    > context) gets converted to a pointer to its first element
    > that it has become common lingo to call that also "a poin-
    > ter to the array" when it actually just is a pointer to the
    > first element.


    It's not just a pointer to the first element. It's a pointer that can be
    offset to index the array.


    > Perhaps unfortunate, but that's life. And when
    > you go to the next point in the C FAQ (6.3 instead of 6.2)
    >
    > http://c-faq.com/aryptr/aryptrequiv.html
    >
    > you will find that it then goes into greater detail, explicitly
    > speaking about the "first element of an array":
    >

    Yes and there is nothing wrong with being specific about what element a
    pointer points to. But there is something wrong if you treat the pointer as
    if it ONLY points to that element, and is not also a pointer to the array.


    > | A reference to an object of type array-of-T which appears
    > | in an expression decays (with three exceptions) into a pointer
    > | to its first element; the type of the resultant pointer is
    > | pointer-to-T.
    >
    > The word "decays" seems to be at the heart of many misunder-
    > standings: this is a conversion the compiler does under cer-
    > tain circumstances but does not imply equality.
    >

    The term decays is used , becasue an array has typeinfo which is lost when
    its converted to a pointer.

    >> >> char* p= new char[64];
    >> >> The above is a pointer points to an array of 64 chars.
    >> >
    >> > No, that's a pointer to a single char, the one at the
    >> > very start of the array. If you want a pointer to an
    >> > array of 64 chars you need
    >> >
    >> > char (*p64)[64];
    >> >

    >> Ok so this is also wrong?
    >> <quote ref=http://www2.research.att.com/~bs/glossary.html>
    >> "char* - pointer to a char or an array of char."
    >> </quote>

    >
    > Again lingo, not wrong when meant in the right way, just a
    > bit sloppily expressed. It might have been better if he had
    > said "...or the first element of an array", but then this is
    > a glossary, not an in-depth explanation.
    >

    Again why would he say pointer the nth element, when the pointer can point
    to any element?


    >> > It's really simple: If you increment a pointer by 1 it
    >> > always points to the address directly behind the object
    >> > it pointed to (its value is increased by the size of the
    >> > type of object it points to). And if you incrememt 'p'
    >> > by 1 it points to the next char in the array, so it's a
    >> > pointer to a single char, not an array of so many chars.
    >> > That it points to the first element of the array doesn't
    >> > change anything about that. But if you increment 'p64' by
    >> > 1 it points directly past the end of the array, so that's
    >> > a pointer to an array of 64 chars.
    >> >
    >> > Perhaps you should read Chris Torek's nice article about
    >> > pointers and arrays
    >> >
    >> > http://web.torek.net/torek/c/pa.html
    >> >
    >> > and also
    >> >
    >> > http://web.torek.net/torek/c/expr.html#therule
    >> >
    >> > (which might address the reasons behind your confusion).
    >> > While it's about C C++ works the same way.
    >> >

    >> Thanks for your post but I think you should read the quotes I posted
    >> above
    >> from Bjarbne Stroustrup and Steve Summit.

    >
    > I did but I don't think they really support your point of view.
    >

    \They clearly state exactly my POV.
    That a char* can point to a single char or an array of chars.
     
    Paul, Apr 18, 2011
    #15
  16. Paul <> wrote:

    > "Jens Thoms Toerring" <> wrote in message
    > news:-berlin.de...
    > > Paul <> wrote:
    > >
    > >> "Jens Thoms Toerring" <> wrote in message
    > >> news:-berlin.de...
    > >> > Paul <> wrote:
    > >> >
    > >> >> A char* can point to a single char or an array of chars.
    > >> >
    > >> > No.
    > >> >
    > >> Ah so this is wrong?

    > >
    > >> <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    > >> "The pointer declaration char *p, on the other hand, requests a place
    > >> which
    > >> holds a pointer, to be known by the name ``p''. This pointer can point
    > >> almost anywhere: to any char, or to any contiguous array of chars, or
    > >> nowhere"
    > >> </quote>

    > >
    > > Sloppy speaking. What's really meant is "to the first element
    > > of any continuous array" (and then we could also ask "what's
    > > a non-continous array?").

    > How do you know he means pointing to the first element of an array?
    > The pointer can point to any element or even to the end of the array.


    > And what is a non-continuous array then? I think C++ arrays are guaranteed
    > to be contiguous.


    I don't know, I just meant that as an example that there are
    also other places were the formulation leaves a bit to be
    wished for. But then a FAQ should be readable and, as every
    explanation, somethimes small white lies are useful to avoid
    getting the reader confused with too many concepts at once.
    You only have to make it clear further on that this was not
    the complete picture...

    > >Since a char and an array of chars
    > > are completely different types a pointer to char can only
    > > point to a char, not also at the same time to the different
    > > type of array of chars - only to an element of the array.


    > A char within an array is the same type as a single char.
    > What type of object do you think an array of chars contains, if not a char
    > type?


    I never made any claims otherwise. The important difference
    is that a pointer to a char points always to a single char
    while a pointer to an array points to a continuous collec-
    tion of chars, involving e.g. information about the number
    of elements. You can obtain that information from a pointer
    to an array of chars, but not from a mere pointer to one
    of it's elements, be it the first or any other.

    > >But
    > > there are so many cases were an array (when used in value
    > > context) gets converted to a pointer to its first element
    > > that it has become common lingo to call that also "a poin-
    > > ter to the array" when it actually just is a pointer to the
    > > first element.


    > It's not just a pointer to the first element. It's a pointer that can be
    > offset to index the array.


    Yes, as well as you can add some value to it. So what?
    But you can't make it jump just to the end of the array
    unless you have external information about how long the
    array is. With a pointer to an array you can't access the
    individual elements directly but you can junp to the end
    of it (or the next array, if you have an array of arrays).

    > > Perhaps unfortunate, but that's life. And when
    > > you go to the next point in the C FAQ (6.3 instead of 6.2)
    > >
    > > http://c-faq.com/aryptr/aryptrequiv.html
    > >
    > > you will find that it then goes into greater detail, explicitly
    > > speaking about the "first element of an array":
    > >

    > Yes and there is nothing wrong with being specific about what element a
    > pointer points to. But there is something wrong if you treat the pointer as
    > if it ONLY points to that element, and is not also a pointer to the array.


    Again, an array is a completely different beast from an
    element of it. These are two different types. And a pointer
    can only have a single type, the type it was created with.
    So a pointer to char is not a pointer to an array of chars,
    it remains a pointer to char whereever you make it point to.
    Just because you store the address of the first element of
    an array in it, which has the same address as the array it-
    self, does not make it a pointer to the array.

    A pointer does not only have a value but also has a type.
    That two pointer of different types have the same value does
    not make them equal.

    Perhaps you have spent a long time doing assembler program-
    ming. There, if two addresses are the same that's all you
    care about. But when you go to a languages with a type
    system things are different. It isn't just about memory
    addresses anymore. Suddenly, two addresses being the same
    isn't all there is since pointers with different types also
    have different properties, like different behaviour when
    being incremented. They add a new meaning that can't be
    expressed in terms of just their values. A lot of things
    become simpler but at the cost of having to think in two
    and not just one "dimension" - value and type instead of
    just value.

    > > | A reference to an object of type array-of-T which appears
    > > | in an expression decays (with three exceptions) into a pointer
    > > | to its first element; the type of the resultant pointer is
    > > | pointer-to-T.
    > >
    > > The word "decays" seems to be at the heart of many misunder-
    > > standings: this is a conversion the compiler does under cer-
    > > tain circumstances but does not imply equality.
    > >

    > The term decays is used , becasue an array has typeinfo which is lost when
    > its converted to a pointer.


    Yes, and because that loss of information would not happen
    when you go from an array-of-T to an pointer-to-array-of-T.
    The type array-to-T e.g. "knows" abouth the number of ele-
    ments, as does the type pointer-to-array-of-T, while the
    type pointer-to-T has no notion at all of something like
    "numbers of elements" - there are no elements, just a
    pointer to a single instance of T.

    > >> >> char* p= new char[64];
    > >> >> The above is a pointer points to an array of 64 chars.
    > >> >
    > >> > No, that's a pointer to a single char, the one at the
    > >> > very start of the array. If you want a pointer to an
    > >> > array of 64 chars you need
    > >> >
    > >> > char (*p64)[64];
    > >> >
    > >> Ok so this is also wrong?
    > >> <quote ref=http://www2.research.att.com/~bs/glossary.html>
    > >> "char* - pointer to a char or an array of char."
    > >> </quote>

    > >
    > > Again lingo, not wrong when meant in the right way, just a
    > > bit sloppily expressed. It might have been better if he had
    > > said "...or the first element of an array", but then this is
    > > a glossary, not an in-depth explanation.
    > >

    > Again why would he say pointer the nth element, when the pointer can point
    > to any element?


    > >> > It's really simple: If you increment a pointer by 1 it
    > >> > always points to the address directly behind the object
    > >> > it pointed to (its value is increased by the size of the
    > >> > type of object it points to). And if you incrememt 'p'
    > >> > by 1 it points to the next char in the array, so it's a
    > >> > pointer to a single char, not an array of so many chars.
    > >> > That it points to the first element of the array doesn't
    > >> > change anything about that. But if you increment 'p64' by
    > >> > 1 it points directly past the end of the array, so that's
    > >> > a pointer to an array of 64 chars.
    > >> >
    > >> > Perhaps you should read Chris Torek's nice article about
    > >> > pointers and arrays
    > >> >
    > >> > http://web.torek.net/torek/c/pa.html
    > >> >
    > >> > and also
    > >> >
    > >> > http://web.torek.net/torek/c/expr.html#therule
    > >> >
    > >> > (which might address the reasons behind your confusion).
    > >> > While it's about C C++ works the same way.
    > >> >
    > >> Thanks for your post but I think you should read the quotes I posted
    > >> above
    > >> from Bjarbne Stroustrup and Steve Summit.

    > >
    > > I did but I don't think they really support your point of view.
    > >

    > \They clearly state exactly my POV.
    > That a char* can point to a single char or an array of chars.


    Why then does incrementing pointers of different types re-
    sult in different values? You seem to be avoiding that point.
    Or you're using your private definition of "pointer", probably
    one that turns a blind eye to pointers having a type beside a
    value. That's nothing I'm going to have sleepness nights about,
    but it makes discussions a bit difficult and, if you insist on
    your definition, futile in the longer (or even shorter) run.

    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Apr 19, 2011
    #16
  17. Paul

    Paul Guest

    "Jens Thoms Toerring" <> wrote in message
    news:-berlin.de...
    > Paul <> wrote:
    >> >> >
    >> >> >> A char* can point to a single char or an array of chars.
    >> >> >
    >> >> > No.
    >> >> >
    >> >> Ah so this is wrong?
    >> >
    >> >> <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    >> >> "The pointer declaration char *p, on the other hand, requests a place
    >> >> which
    >> >> holds a pointer, to be known by the name ``p''. This pointer can point
    >> >> almost anywhere: to any char, or to any contiguous array of chars, or
    >> >> nowhere"
    >> >> </quote>
    >> >
    >> > Sloppy speaking. What's really meant is "to the first element
    >> > of any continuous array" (and then we could also ask "what's
    >> > a non-continous array?").

    >> How do you know he means pointing to the first element of an array?
    >> The pointer can point to any element or even to the end of the array.

    >
    >> And what is a non-continuous array then? I think C++ arrays are
    >> guaranteed
    >> to be contiguous.

    >
    > I don't know, I just meant that as an example that there are
    > also other places were the formulation leaves a bit to be
    > wished for. But then a FAQ should be readable and, as every
    > explanation, somethimes small white lies are useful to avoid
    > getting the reader confused with too many concepts at once.
    > You only have to make it clear further on that this was not
    > the complete picture...
    >
    >> >Since a char and an array of chars
    >> > are completely different types a pointer to char can only
    >> > point to a char, not also at the same time to the different
    >> > type of array of chars - only to an element of the array.

    >
    >> A char within an array is the same type as a single char.
    >> What type of object do you think an array of chars contains, if not a
    >> char
    >> type?

    >
    > I never made any claims otherwise. The important difference
    > is that a pointer to a char points always to a single char


    This is not true. A pointer is a varaible with a memory address for a value.
    The object stored at the memory location is not defined by the pointer-type,
    for example:
    int x =0;
    char* p = 0;
    p= (char*)&x;
    p[2] =1;

    The pointer-type is char* , but its initialised to point to nothing, then it
    is assgined the address of an int. At no time does this pointer point to an
    object of type char.


    > while a pointer to an array points to a continuous collec-
    > tion of chars, involving e.g. information about the number
    > of elements. You can obtain that information from a pointer
    > to an array of chars, but not from a mere pointer to one
    > of it's elements, be it the first or any other.

    This is a pointer to an array type.
    You need to acknowledge that an array-type is not the same as an array
    entity.
    When we say a char* can point to an array we are speaking about an array
    entity.
    When an array is converted to a pointer, the pointer-type is a pointer to a
    (n-1) dimensional array.

    You can't say a statement such as "a char* can point to an array of chars"
    is sloppy because you have interpreted it incorrectly. You are confusing the
    obvious(IMO) context of an array entity, with array-type.

    >
    >> >But
    >> > there are so many cases were an array (when used in value
    >> > context) gets converted to a pointer to its first element
    >> > that it has become common lingo to call that also "a poin-
    >> > ter to the array" when it actually just is a pointer to the
    >> > first element.

    >
    >> It's not just a pointer to the first element. It's a pointer that can be
    >> offset to index the array.

    >
    > Yes, as well as you can add some value to it. So what?
    > But you can't make it jump just to the end of the array
    > unless you have external information about how long the
    > array is. With a pointer to an array you can't access the
    > individual elements directly but you can junp to the end
    > of it (or the next array, if you have an array of arrays).


    If you cannot access the array , then its not a pointer to the array.
    A pointer to an array , when dereferenced must access the array.

    What you describe is an indirect pointer to an array, you must dereference
    it twice to access the array.

    >
    >> > Perhaps unfortunate, but that's life. And when
    >> > you go to the next point in the C FAQ (6.3 instead of 6.2)
    >> >
    >> > http://c-faq.com/aryptr/aryptrequiv.html
    >> >
    >> > you will find that it then goes into greater detail, explicitly
    >> > speaking about the "first element of an array":
    >> >

    >> Yes and there is nothing wrong with being specific about what element a
    >> pointer points to. But there is something wrong if you treat the pointer
    >> as
    >> if it ONLY points to that element, and is not also a pointer to the
    >> array.

    >
    > Again, an array is a completely different beast from an
    > element of it. These are two different types.


    An array of chars is not a type, its an entity.


    > And a pointer
    > can only have a single type, the type it was created with.
    > So a pointer to char is not a pointer to an array of chars,
    > it remains a pointer to char whereever you make it point to.
    > Just because you store the address of the first element of
    > an array in it, which has the same address as the array it-
    > self, does not make it a pointer to the array.
    >

    A pointer of type char* can point to an array of chars, when dereferenced it
    returns one element of the array.
    You cannot get any pointer type that addresses a whole array simultaneously,
    unless the array is sized one or something silly like that.


    > A pointer does not only have a value but also has a type.
    > That two pointer of different types have the same value does
    > not make them equal.

    This depends on what you mean by being equal.
    are the following two variables equal:
    int x=0
    char c=0;

    >
    > Perhaps you have spent a long time doing assembler program-
    > ming. There, if two addresses are the same that's all you
    > care about. But when you go to a languages with a type
    > system things are different. It isn't just about memory
    > addresses anymore. Suddenly, two addresses being the same
    > isn't all there is since pointers with different types also
    > have different properties, like different behaviour when
    > being incremented. They add a new meaning that can't be
    > expressed in terms of just their values. A lot of things
    > become simpler but at the cost of having to think in two
    > and not just one "dimension" - value and type instead of
    > just value.
    >

    Yes there is obviously a difference in opinions on this. I think neither POV
    can be said to be right or wrong.

    But having this acceptance for others' POV I feel its wrong to suggest one
    POV is sloppy and somehow incorrect when it's a failure to understand the
    other POV.

    >> > | A reference to an object of type array-of-T which appears
    >> > | in an expression decays (with three exceptions) into a pointer
    >> > | to its first element; the type of the resultant pointer is
    >> > | pointer-to-T.
    >> >
    >> > The word "decays" seems to be at the heart of many misunder-
    >> > standings: this is a conversion the compiler does under cer-
    >> > tain circumstances but does not imply equality.
    >> >

    >> The term decays is used , becasue an array has typeinfo which is lost
    >> when
    >> its converted to a pointer.

    >
    > Yes, and because that loss of information would not happen
    > when you go from an array-of-T to an pointer-to-array-of-T.
    > The type array-to-T e.g. "knows" abouth the number of ele-
    > ments, as does the type pointer-to-array-of-T, while the
    > type pointer-to-T has no notion at all of something like
    > "numbers of elements" - there are no elements, just a
    > pointer to a single instance of T.
    >

    But sometimes you don't need the type info.
    And often you have no option because you are using a function that takes a
    pointer to an array , not a reference.
    Perhaps it would be better if C++ pointers to array were of the type you
    describe but this is not the case , I think we are stuck with the present
    case which we inhereted from C



    >> >> >> char* p= new char[64];
    >> >> >> The above is a pointer points to an array of 64 chars.
    >> >> >
    >> >> > No, that's a pointer to a single char, the one at the
    >> >> > very start of the array. If you want a pointer to an
    >> >> > array of 64 chars you need
    >> >> >
    >> >> > char (*p64)[64];
    >> >> >
    >> >> Ok so this is also wrong?
    >> >> <quote ref=http://www2.research.att.com/~bs/glossary.html>
    >> >> "char* - pointer to a char or an array of char."
    >> >> </quote>
    >> >
    >> > Again lingo, not wrong when meant in the right way, just a
    >> > bit sloppily expressed. It might have been better if he had
    >> > said "...or the first element of an array", but then this is
    >> > a glossary, not an in-depth explanation.
    >> >

    >> Again why would he say pointer the nth element, when the pointer can
    >> point
    >> to any element?

    >
    >> >> > It's really simple: If you increment a pointer by 1 it
    >> >> > always points to the address directly behind the object
    >> >> > it pointed to (its value is increased by the size of the
    >> >> > type of object it points to). And if you incrememt 'p'
    >> >> > by 1 it points to the next char in the array, so it's a
    >> >> > pointer to a single char, not an array of so many chars.
    >> >> > That it points to the first element of the array doesn't
    >> >> > change anything about that. But if you increment 'p64' by
    >> >> > 1 it points directly past the end of the array, so that's
    >> >> > a pointer to an array of 64 chars.
    >> >> >
    >> >> > Perhaps you should read Chris Torek's nice article about
    >> >> > pointers and arrays
    >> >> >
    >> >> > http://web.torek.net/torek/c/pa.html
    >> >> >
    >> >> > and also
    >> >> >
    >> >> > http://web.torek.net/torek/c/expr.html#therule
    >> >> >
    >> >> > (which might address the reasons behind your confusion).
    >> >> > While it's about C C++ works the same way.
    >> >> >
    >> >> Thanks for your post but I think you should read the quotes I posted
    >> >> above
    >> >> from Bjarbne Stroustrup and Steve Summit.
    >> >
    >> > I did but I don't think they really support your point of view.
    >> >

    >> \They clearly state exactly my POV.
    >> That a char* can point to a single char or an array of chars.

    >
    > Why then does incrementing pointers of different types re-
    > sult in different values? You seem to be avoiding that point.
    > Or you're using your private definition of "pointer", probably
    > one that turns a blind eye to pointers having a type beside a
    > value. That's nothing I'm going to have sleepness nights about,
    > but it makes discussions a bit difficult and, if you insist on
    > your definition, futile in the longer (or even shorter) run.
    >

    I don't see that I'm avoiding anything.
    You ask why does incremeenting pointers of different types result in
    different values.

    I think you mean by different values , you probably mean different stepping
    increments and not the value of the pointer.
    The way I see it an array is converted to a pointer of type pointer to (n-1)
    dimensional array. So with a 2dim array the pointer-type it's converted to
    is:
    T (*)[Dim2]

    incrementing this pointer-type would result in stepping increments
    sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
    allows the following 2d subscripting with 2d array pointers:
    p[0][0];
     
    Paul, Apr 19, 2011
    #17
  18. Paul <> wrote:
    > "Jens Thoms Toerring" <> wrote in message
    > news:-berlin.de...
    > > Paul <> wrote:
    > >> >> >
    > >> >> >> A char* can point to a single char or an array of chars.
    > >> >> >
    > >> >> > No.
    > >> >> >
    > >> >> Ah so this is wrong?
    > >> >
    > >> >> <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    > >> >> "The pointer declaration char *p, on the other hand, requests a place
    > >> >> which
    > >> >> holds a pointer, to be known by the name ``p''. This pointer can point
    > >> >> almost anywhere: to any char, or to any contiguous array of chars, or
    > >> >> nowhere"
    > >> >> </quote>
    > >> >
    > >> > Sloppy speaking. What's really meant is "to the first element
    > >> > of any continuous array" (and then we could also ask "what's
    > >> > a non-continous array?").
    > >> How do you know he means pointing to the first element of an array?
    > >> The pointer can point to any element or even to the end of the array.

    > >
    > >> And what is a non-continuous array then? I think C++ arrays are
    > >> guaranteed
    > >> to be contiguous.

    > >
    > > I don't know, I just meant that as an example that there are
    > > also other places were the formulation leaves a bit to be
    > > wished for. But then a FAQ should be readable and, as every
    > > explanation, somethimes small white lies are useful to avoid
    > > getting the reader confused with too many concepts at once.
    > > You only have to make it clear further on that this was not
    > > the complete picture...
    > >
    > >> >Since a char and an array of chars
    > >> > are completely different types a pointer to char can only
    > >> > point to a char, not also at the same time to the different
    > >> > type of array of chars - only to an element of the array.

    > >
    > >> A char within an array is the same type as a single char.
    > >> What type of object do you think an array of chars contains, if not a
    > >> char
    > >> type?

    > >
    > > I never made any claims otherwise. The important difference
    > > is that a pointer to a char points always to a single char


    > This is not true. A pointer is a varaible with a memory address
    > for a value.


    You're again thinking only in terms of the values of pointers,
    i.e. memory addresses, and are disregarding that a pointer is
    more than an address - it has another quality, it got 'type'.

    > The object stored at the memory location is not

    defined by the pointer-type,
    > for example:
    > int x =0;
    > char* p = 0;
    > p= (char*)&x;
    > p[2] =1;


    > The pointer-type is char* , but its initialised to point to nothing,
    > then it is assgined the address of an int. At no time does this
    > pointer point to an object of type char.


    When you dereference the char pointer the compiler will
    extract a value of type char from that location. By poin-
    ting a char pointer to an address you promise the compiler
    that it can extract a char value from there when asked to.
    That's not a big problem with chars - since they are the
    smallest addressable unit you hardly can go wrong with that.

    The other way round (assuming an int with 4 bytes)

    char y[ ] = "abcd";
    int * ip = ( int * ) &y;

    you're already into deeper trouble. If you use 'ip' to get
    at an int value stored in that location you get away with
    that on a number of architectures all of the time, but on
    others, if you're unlucky, your program will crash with a
    bus error since the array of chars may not be properly
    aligned for an int access.

    And then, when you convert from one type to another, you
    have to go to some effort, especially under C++. C is
    somewhat more relaxed about that since it was intorduced
    forprogramming near to the metal were most people had a
    good idea what can be done and what to avoid. C++ tightens
    the rules quite a bit to keep people from making mistakes
    but still lets you do a lot of things that are against the
    type system (making casts more ugly and harder to write
    is another way to dicourage people to use them). So, yes,
    you can work against the type system, but at your own peril
    - and then, if you do, it's advantageous if you understand
    what you're doing.

    > > while a pointer to an array points to a continuous collec-
    > > tion of chars, involving e.g. information about the number
    > > of elements. You can obtain that information from a pointer
    > > to an array of chars, but not from a mere pointer to one
    > > of it's elements, be it the first or any other.

    > This is a pointer to an array type.
    >
    > You need to acknowledge that an array-type is not the same as an array
    > entity.


    I don't know exactly what an 'array entity' is supposed to mean.
    If it means a "real array" I use in my program, then yes, of
    course, it's something different. The same way a table isn't
    the same as the word "table".

    > When we say a char* can point to an array we are speaking about an
    > array entity.


    You are, again, disregarding 'type'. I never claimed that an
    array has not the same address as its first element. But hol-
    ding the same address does not make two pointers identical
    if they have different types. If I have a laser shining at
    my head at same time stand in the sun that doesn't make the
    laser the same as the sun just because they both illuminate
    my head. Two pointers of different types behave differently,
    even if they point to the same memory location.

    Or take an example that doesn't involve pointers at all:

    usigned char c = 0;
    unsigned long l = 0;

    You're arguing that they are the same since they both have
    the same value. But now let's do the exact same thing to
    both variables:

    c += 2263576;
    l += 2263576;

    And now it becomes (at least on "normal" machines, where
    the range of a char is rather limited) that they are not
    the same at all, you just have to compare their values.
    So their different types make a lot of a difference, even
    if both started of with the same value and the exact same
    operation was applied to them.

    > When an array is converted to a pointer, the pointer-type is a
    > pointer to a (n-1) dimensional array.


    I go into that at the end.

    > You can't say a statement such as "a char* can point to an array of chars"
    > is sloppy because you have interpreted it incorrectly. You are confusing the
    > obvious(IMO) context of an array entity, with array-type.


    I have no problem saying that. It may be ok to say "a char *
    points to an array" when everyone around understands that
    this is just short for "points to the first element of an
    array" and I don't want to sound pompous or like a buro-
    crat but that doesn't make it a precise statement.

    > >> >But
    > >> > there are so many cases were an array (when used in value
    > >> > context) gets converted to a pointer to its first element
    > >> > that it has become common lingo to call that also "a poin-
    > >> > ter to the array" when it actually just is a pointer to the
    > >> > first element.

    > >
    > >> It's not just a pointer to the first element. It's a pointer that can be
    > >> offset to index the array.

    > >
    > > Yes, as well as you can add some value to it. So what?
    > > But you can't make it jump just to the end of the array
    > > unless you have external information about how long the
    > > array is. With a pointer to an array you can't access the
    > > individual elements directly but you can junp to the end
    > > of it (or the next array, if you have an array of arrays).


    > If you cannot access the array , then its not a pointer to the array.
    > A pointer to an array , when dereferenced must access the array.


    Of course, you can access the array, I never said anything
    else. You just can't directly access its individual elements
    of the array. The same way you can't directly access the in-
    dividiual members of a structure when you have a pointer to
    a structure. The pointer to the structure points to the
    structure as a whole (even when that is the same address as
    the first member) and you need some extra syntax to get at
    its members.

    Actually, according to your line of arguments you also should
    say that with

    struct {
    int x;
    int y;
    } z;

    int * ix = ( int * ) &z;

    'ix' is now a pointer to the structure. It's value is the
    same as the address of 'z', so, according to your criteria,
    it should be a pointer to the structure. But do you really
    think so?

    > What you describe is an indirect pointer to an array, you must dereference
    > it twice to access the array.


    No. There is a difference between accessing an array and
    accessing an element of an array. An array is a structured
    blob in memory the same way e.g. a structure is. And a
    pointer to an array points to that blob. Getting at its
    innards need a bit more work, as it is needed for getting
    at the members of a structure. That you can't write an
    element access like e.g. 'ap->[1]' (which would be 'sym-
    metric to how one would deal with a structure pointer) is
    just the "fault" of the language and you thus have to re-
    sort to the more ugly '(*ap)[1]', in e.g. Perl that's quite
    fine when you have a pointer (reference) to an array.

    > >> > Perhaps unfortunate, but that's life. And when
    > >> > you go to the next point in the C FAQ (6.3 instead of 6.2)
    > >> >
    > >> > http://c-faq.com/aryptr/aryptrequiv.html
    > >> >
    > >> > you will find that it then goes into greater detail, explicitly
    > >> > speaking about the "first element of an array":
    > >> >
    > >> Yes and there is nothing wrong with being specific about what element a
    > >> pointer points to. But there is something wrong if you treat the pointer
    > >> as
    > >> if it ONLY points to that element, and is not also a pointer to the
    > >> array.

    > >
    > > Again, an array is a completely different beast from an
    > > element of it. These are two different types.


    > An array of chars is not a type, its an entity.


    I never said that an array of chars "is" a type, I said
    it "has" a type - beside its property of consisting of a
    number of bytes. We're not discussing assembler here, the
    language adds types to entities when we progrm in that
    language and we need to consider that. What later happens
    at the execution phase is something different. There is no
    1-to-1 mappin between the language and what the processor
    does when the program has been compiled. Otherwise using a
    computer language would be useless.

    > > And a pointer
    > > can only have a single type, the type it was created with.
    > > So a pointer to char is not a pointer to an array of chars,
    > > it remains a pointer to char whereever you make it point to.
    > > Just because you store the address of the first element of
    > > an array in it, which has the same address as the array it-
    > > self, does not make it a pointer to the array.
    > >

    > A pointer of type char* can point to an array of chars, when dereferenced it
    > returns one element of the array.
    > You cannot get any pointer type that addresses a whole array simultaneously,
    > unless the array is sized one or something silly like that.


    > > A pointer does not only have a value but also has a type.
    > > That two pointer of different types have the same value does
    > > not make them equal.

    > This depends on what you mean by being equal.
    > are the following two variables equal:
    > int x=0
    > char c=0;


    No, they aren't, see above.

    > > Perhaps you have spent a long time doing assembler program-
    > > ming. There, if two addresses are the same that's all you
    > > care about. But when you go to a languages with a type
    > > system things are different. It isn't just about memory
    > > addresses anymore. Suddenly, two addresses being the same
    > > isn't all there is since pointers with different types also
    > > have different properties, like different behaviour when
    > > being incremented. They add a new meaning that can't be
    > > expressed in terms of just their values. A lot of things
    > > become simpler but at the cost of having to think in two
    > > and not just one "dimension" - value and type instead of
    > > just value.
    > >

    > Yes there is obviously a difference in opinions on this. I think neither POV
    > can be said to be right or wrong.


    I don't think so. I feel that you're missing an important
    point, i.e. that a computer language is more than just
    about bits and bytes. It adds completely new levels of mea-
    ning that can't be understood in terms of what happpens at
    the register and memory level. This allow you to get away
    from thinking just in categories of bytes and what happens
    to them and instead lets you concentrate on the problem do-
    main. Like, when you write "car->turn( 30 );" in an OOP
    program you aren't supposed to keep in mind what that does
    in terms of what happens in the CPU, you should keep focused
    on what the class 'car' is an instance of will do with that.

    > But having this acceptance for others' POV I feel its wrong to suggest one
    > POV is sloppy and somehow incorrect when it's a failure to understand the
    > other POV.


    You're in a good mood tonight;-) But, sorry, I think your
    POV is wrong, or at least misses an important aspect.

    > >> > | A reference to an object of type array-of-T which appears
    > >> > | in an expression decays (with three exceptions) into a pointer
    > >> > | to its first element; the type of the resultant pointer is
    > >> > | pointer-to-T.
    > >> >
    > >> > The word "decays" seems to be at the heart of many misunder-
    > >> > standings: this is a conversion the compiler does under cer-
    > >> > tain circumstances but does not imply equality.
    > >> >
    > >> The term decays is used , becasue an array has typeinfo which is lost
    > >> when
    > >> its converted to a pointer.

    > >
    > > Yes, and because that loss of information would not happen
    > > when you go from an array-of-T to an pointer-to-array-of-T.
    > > The type array-to-T e.g. "knows" abouth the number of ele-
    > > ments, as does the type pointer-to-array-of-T, while the
    > > type pointer-to-T has no notion at all of something like
    > > "numbers of elements" - there are no elements, just a
    > > pointer to a single instance of T.
    > >

    > But sometimes you don't need the type info.
    > And often you have no option because you are using a function that takes a
    > pointer to an array , not a reference.


    But regardles if I want the type or not it's there, given by the
    language I'm using.

    > Perhaps it would be better if C++ pointers to array were of the type you
    > describe but this is not the case , I think we are stuck with the present
    > case which we inhereted from C


    I'm not really religious about the way it's done in C or C++.
    And passing a pointer to an array would require other changes
    in the language. Since an array has a well-defined length you
    would need a functions for each length of array. To avoid
    that You would need to change C++ so that it would accept an
    argument of 'pointer to array of unspecified length' but still
    be able to get at the length - or you'd be back to square one,
    i.e. you'd would have to pass a length with the pointer to the
    array. And when we would need that then it would make no sense
    at all, there would hardly any difference to what we have now.

    > >> >> >> char* p= new char[64];
    > >> >> >> The above is a pointer points to an array of 64 chars.
    > >> >> >
    > >> >> > No, that's a pointer to a single char, the one at the
    > >> >> > very start of the array. If you want a pointer to an
    > >> >> > array of 64 chars you need
    > >> >> >
    > >> >> > char (*p64)[64];
    > >> >> >
    > >> >> Ok so this is also wrong?
    > >> >> <quote ref=http://www2.research.att.com/~bs/glossary.html>
    > >> >> "char* - pointer to a char or an array of char."
    > >> >> </quote>
    > >> >
    > >> > Again lingo, not wrong when meant in the right way, just a
    > >> > bit sloppily expressed. It might have been better if he had
    > >> > said "...or the first element of an array", but then this is
    > >> > a glossary, not an in-depth explanation.
    > >> >
    > >> Again why would he say pointer the nth element, when the pointer can
    > >> point
    > >> to any element?

    > >
    > >> >> > It's really simple: If you increment a pointer by 1 it
    > >> >> > always points to the address directly behind the object
    > >> >> > it pointed to (its value is increased by the size of the
    > >> >> > type of object it points to). And if you incrememt 'p'
    > >> >> > by 1 it points to the next char in the array, so it's a
    > >> >> > pointer to a single char, not an array of so many chars.
    > >> >> > That it points to the first element of the array doesn't
    > >> >> > change anything about that. But if you increment 'p64' by
    > >> >> > 1 it points directly past the end of the array, so that's
    > >> >> > a pointer to an array of 64 chars.
    > >> >> >
    > >> >> > Perhaps you should read Chris Torek's nice article about
    > >> >> > pointers and arrays
    > >> >> >
    > >> >> > http://web.torek.net/torek/c/pa.html
    > >> >> >
    > >> >> > and also
    > >> >> >
    > >> >> > http://web.torek.net/torek/c/expr.html#therule
    > >> >> >
    > >> >> > (which might address the reasons behind your confusion).
    > >> >> > While it's about C C++ works the same way.
    > >> >> >
    > >> >> Thanks for your post but I think you should read the quotes I posted
    > >> >> above
    > >> >> from Bjarbne Stroustrup and Steve Summit.
    > >> >
    > >> > I did but I don't think they really support your point of view.
    > >> >
    > >> \They clearly state exactly my POV.
    > >> That a char* can point to a single char or an array of chars.

    > >
    > > Why then does incrementing pointers of different types re-
    > > sult in different values? You seem to be avoiding that point.
    > > Or you're using your private definition of "pointer", probably
    > > one that turns a blind eye to pointers having a type beside a
    > > value. That's nothing I'm going to have sleepness nights about,
    > > but it makes discussions a bit difficult and, if you insist on
    > > your definition, futile in the longer (or even shorter) run.
    > >

    > I don't see that I'm avoiding anything.
    > You ask why does incremeenting pointers of different types result in
    > different values.


    > I think you mean by different values , you probably mean different stepping
    > increments and not the value of the pointer.


    The values of the two pointers 'p' and 'p64'

    char x[ 64 ];
    char *p = x;
    char ( *p64 )[ 64 ] = &x;

    are the same now but will definitely be different after you did

    p++;
    p64++;

    The first one will point to the second element of the array 'x',
    the other will point directly after the end of 'x'. So I would
    call that a different value, wouldn't you? And that's one of
    the differences in behaviour that's due to the different types
    of the pointers.

    > The way I see it an array is converted to a pointer of type pointer to (n-1)
    > dimensional array. So with a 2dim array the pointer-type it's converted to
    > is:
    > T (*)[Dim2]


    > incrementing this pointer-type would result in stepping increments
    > sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
    > allows the following 2d subscripting with 2d array pointers:
    > p[0][0];


    Nice point you're giving me there;-) If you have e.g.

    int a[ 3 ][ 5 ];

    then you need

    int ( *ap )[ 5 ] = a;

    i.e. 'a' "decays" to a real 1D array pointer like the one I des-
    cribed before. And are you now going to argue that '(*ap)[5]' is
    a pointer to a two-dimensional array as it would seem logical to
    me when you claim that 'char *' is also a pointer to an array?

    To me it looks like a pointer to a 1-dimensional array as this
    example program perhaps can illustrate

    #include <iostream>
    int main( )
    {
    int a[ 3 ] = { 1, 2, 3 };
    int ( *ap )[ 3 ] = &a;
    int b[ 3 ][ 2 ] = { { 7, 9,}, { -4, 5,}, { 8, -5 } };
    int ( *bp )[ 2 ] = b;
    std::cout << ( *ap )[ 1 ] << ' ' << ( *bp )[ 1 ] << '\n';
    }

    - both 'ap' and 'bp' seem to me to have the same type.

    As you say, this conversion ("decaying" when an array is used
    in a context where a value is expected) reduces the dimension
    by 1. But that does not make the thing on the left and right
    hand side the same - the equal sign is even more out of place
    here then it is everywhere else (when you consider its mathe-
    matical meaning). This is basically an overloding of the '='
    operator to get any sense out of that expression since an
    array (whatever it's dimension) simply has no value in C or
    C++ and thus such an expression would be meaningless other-
    wise. (Or arrays would have to be made "first-class" citi-
    zens of C and C++, so that you could assign one array to
    another with '=' and pass it by value to a function, as you
    can do with structures or class instances.)

    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Apr 19, 2011
    #18
  19. Paul

    Paul Guest

    "Jens Thoms Toerring" <> wrote in message
    news:-berlin.de...
    > Paul <> wrote:
    >> >> >> >> A char* can point to a single char or an array of chars.
    >> >> >> >
    >> >> >> > No.
    >> >> >> >
    >> >> >> Ah so this is wrong?
    >> >> >
    >> >> >> <quote ref=http://c-faq.com/aryptr/aryptr2.html>
    >> >> >> "The pointer declaration char *p, on the other hand, requests a
    >> >> >> place
    >> >> >> which
    >> >> >> holds a pointer, to be known by the name ``p''. This pointer can
    >> >> >> point
    >> >> >> almost anywhere: to any char, or to any contiguous array of chars,
    >> >> >> or
    >> >> >> nowhere"
    >> >> >> </quote>
    >> >> >
    >> >> > Sloppy speaking. What's really meant is "to the first element
    >> >> > of any continuous array" (and then we could also ask "what's
    >> >> > a non-continous array?").
    >> >> How do you know he means pointing to the first element of an array?
    >> >> The pointer can point to any element or even to the end of the array.
    >> >
    >> >> And what is a non-continuous array then? I think C++ arrays are
    >> >> guaranteed
    >> >> to be contiguous.
    >> >
    >> > I don't know, I just meant that as an example that there are
    >> > also other places were the formulation leaves a bit to be
    >> > wished for. But then a FAQ should be readable and, as every
    >> > explanation, somethimes small white lies are useful to avoid
    >> > getting the reader confused with too many concepts at once.
    >> > You only have to make it clear further on that this was not
    >> > the complete picture...
    >> >
    >> >> >Since a char and an array of chars
    >> >> > are completely different types a pointer to char can only
    >> >> > point to a char, not also at the same time to the different
    >> >> > type of array of chars - only to an element of the array.
    >> >
    >> >> A char within an array is the same type as a single char.
    >> >> What type of object do you think an array of chars contains, if not a
    >> >> char
    >> >> type?
    >> >
    >> > I never made any claims otherwise. The important difference
    >> > is that a pointer to a char points always to a single char

    >
    >> This is not true. A pointer is a varaible with a memory address
    >> for a value.

    >
    > You're again thinking only in terms of the values of pointers,
    > i.e. memory addresses, and are disregarding that a pointer is
    > more than an address - it has another quality, it got 'type'.

    This is what we are talking about when we say that a char* can point to an
    array of chars, the context if an array is an entity , not a type.

    I think what you say is incorrect and it is in fact it's actually you who
    can only think in terms of an array as a type.


    >
    >> The object stored at the memory location is not

    > defined by the pointer-type,
    >> for example:
    >> int x =0;
    >> char* p = 0;
    >> p= (char*)&x;
    >> p[2] =1;

    >
    >> The pointer-type is char* , but its initialised to point to nothing,
    >> then it is assgined the address of an int. At no time does this
    >> pointer point to an object of type char.

    >
    > When you dereference the char pointer the compiler will
    > extract a value of type char from that location. By poin-
    > ting a char pointer to an address you promise the compiler
    > that it can extract a char value from there when asked to.


    No I dereferenced the char* and I did not extract anything.

    But you seenm to be deviating from the original topic , which is what is
    pointed to .
    So what is pointed to , is it an int object, or a char object?


    > That's not a big problem with chars - since they are the
    > smallest addressable unit you hardly can go wrong with that.
    >
    > The other way round (assuming an int with 4 bytes)
    >
    > char y[ ] = "abcd";
    > int * ip = ( int * ) &y;
    >
    > you're already into deeper trouble.

    No you are in trouble , this is YOUR code not mine.

    >If you use 'ip' to get
    > at an int value stored in that location you get away with
    > that on a number of architectures all of the time, but on
    > others, if you're unlucky, your program will crash with a
    > bus error since the array of chars may not be properly
    > aligned for an int access.

    Its YOUR error here , I don't know what you are talking about , some kinda
    bad coding techniques.

    >
    > And then, when you convert from one type to another, you
    > have to go to some effort, especially under C++. C is
    > somewhat more relaxed about that since it was intorduced
    > forprogramming near to the metal were most people had a
    > good idea what can be done and what to avoid.


    Now you are on about converting types.

    > C++ tightens
    > the rules quite a bit to keep people from making mistakes
    > but still lets you do a lot of things that are against the
    > type system (making casts more ugly and harder to write
    > is another way to dicourage people to use them). So, yes,
    > you can work against the type system, but at your own peril
    > - and then, if you do, it's advantageous if you understand
    > what you're doing.
    >

    Its not working against the type system, its using the type system to your
    benefit.

    When you access an array you want to access one element only. So it only
    makes sense to use a pointer-type that when dereferenced accesses one
    element.
    In fact this is the only technical possibilty on most , if not all ,
    computer systems.
    A computer system cannot have a pointer that can access a whole array
    simultaneously.



    >> > while a pointer to an array points to a continuous collec-
    >> > tion of chars, involving e.g. information about the number
    >> > of elements. You can obtain that information from a pointer
    >> > to an array of chars, but not from a mere pointer to one
    >> > of it's elements, be it the first or any other.

    >> This is a pointer to an array type.
    >>
    >> You need to acknowledge that an array-type is not the same as an array
    >> entity.

    >
    > I don't know exactly what an 'array entity' is supposed to mean.
    > If it means a "real array" I use in my program, then yes, of
    > course, it's something different. The same way a table isn't
    > the same as the word "table".


    I mean a real array, not a type.

    For example and integer is a whole number value , an integer-type is not.
    An array-type is a type. An array is not a type , its a sequence of objects.


    >
    >> When we say a char* can point to an array we are speaking about an
    >> array entity.

    >
    > You are, again, disregarding 'type'. I never claimed that an
    > array has not the same address as its first element.

    I am not disregarding type , I am explained what is meat when we say a char*
    can point to an array.

    You are only thinking of type, it is you who is disregarding the pointed to
    object.

    > But hol-
    > ding the same address does not make two pointers identical
    > if they have different types. If I have a laser shining at
    > my head at same time stand in the sun that doesn't make the
    > laser the same as the sun just because they both illuminate
    > my head. Two pointers of different types behave differently,
    > even if they point to the same memory location.
    >

    Nobody is denying that two different pointer types can point to the same
    location.
    But your example does not change the fact that both pointers point to your
    head. They don't necessarrily only point to your type of head. One of the
    pointer-types could be made to point to , for example, an alien head type.

    > Or take an example that doesn't involve pointers at all:
    >
    > usigned char c = 0;
    > unsigned long l = 0;
    >
    > You're arguing that they are the same since they both have
    > the same value. But now let's do the exact same thing to
    > both variables:
    >
    > c += 2263576;
    > l += 2263576;
    >
    > And now it becomes (at least on "normal" machines, where
    > the range of a char is rather limited) that they are not
    > the same at all, you just have to compare their values.
    > So their different types make a lot of a difference, even
    > if both started of with the same value and the exact same
    > operation was applied to them.
    >

    Here we are talking about equality, the example I gave was two variables ,
    of different-types, which hold the same value. Are they equal?

    If you change the values to create two variables with different values, then
    I don't think the same thing is being expressed.


    >> When an array is converted to a pointer, the pointer-type is a
    >> pointer to a (n-1) dimensional array.

    >
    > I go into that at the end.
    >
    >> You can't say a statement such as "a char* can point to an array of
    >> chars"
    >> is sloppy because you have interpreted it incorrectly. You are confusing
    >> the
    >> obvious(IMO) context of an array entity, with array-type.

    >
    > I have no problem saying that. It may be ok to say "a char *
    > points to an array" when everyone around understands that
    > this is just short for "points to the first element of an
    > array" and I don't want to sound pompous or like a buro-
    > crat but that doesn't make it a precise statement.
    >

    But what if it doesn't point to the first element of the array?
    A pointer to an array doesn't have to point to the first element.



    >> >> >But
    >> >> > there are so many cases were an array (when used in value
    >> >> > context) gets converted to a pointer to its first element
    >> >> > that it has become common lingo to call that also "a poin-
    >> >> > ter to the array" when it actually just is a pointer to the
    >> >> > first element.
    >> >
    >> >> It's not just a pointer to the first element. It's a pointer that can
    >> >> be
    >> >> offset to index the array.
    >> >
    >> > Yes, as well as you can add some value to it. So what?
    >> > But you can't make it jump just to the end of the array
    >> > unless you have external information about how long the
    >> > array is. With a pointer to an array you can't access the
    >> > individual elements directly but you can junp to the end
    >> > of it (or the next array, if you have an array of arrays).

    >
    >> If you cannot access the array , then its not a pointer to the array.
    >> A pointer to an array , when dereferenced must access the array.

    >
    > Of course, you can access the array, I never said anything
    > else. You just can't directly access its individual elements
    > of the array. The same way you can't directly access the in-
    > dividiual members of a structure when you have a pointer to
    > a structure. The pointer to the structure points to the
    > structure as a whole (even when that is the same address as
    > the first member) and you need some extra syntax to get at
    > its members.

    It's not the same at all. A pointer to a structure accesses the structure
    when dereferenced.
    A structure is a type, an array is not a type it is a sequence of objects.
    The type of an array is that of the objects it contains, for exmaple:

    float arr[16];

    The type is float, you just asked the compiler to make 16 of them in
    sequnece. If you want to access one of them you need a float type pointer.
    float* p = arr;

    This is a pointer to the array, its type is float* because when we
    derefernece this pointer we want to access a float object.



    >
    > Actually, according to your line of arguments you also should
    > say that with
    >
    > struct {
    > int x;
    > int y;
    > } z;
    >
    > int * ix = ( int * ) &z;
    >
    > 'ix' is now a pointer to the structure. It's value is the
    > same as the address of 'z', so, according to your criteria,
    > it should be a pointer to the structure. But do you really
    > think so?


    No I would disagree with this , because a structure has diffferent rules for
    memory layout.
    I wouldn't be surprised if dereferencing this pointer resulted in UB.


    >
    >> What you describe is an indirect pointer to an array, you must
    >> dereference
    >> it twice to access the array.

    >
    > No. There is a difference between accessing an array and
    > accessing an element of an array. An array is a structured
    > blob in memory the same way e.g. a structure is.


    I disagree , an array is not the same as a structure.

    > And a
    > pointer to an array points to that blob.

    You cannot get a pointer that, when dereferenced, accessses the whole array.
    You can with a structure.

    > Getting at its
    > innards need a bit more work, as it is needed for getting
    > at the members of a structure. That you can't write an
    > element access like e.g. 'ap->[1]' (which would be 'sym-
    > metric to how one would deal with a structure pointer) is
    > just the "fault" of the language and you thus have to re-
    > sort to the more ugly '(*ap)[1]', in e.g. Perl that's quite
    > fine when you have a pointer (reference) to an array.
    >

    I think you are way off on the wrong track here, arrays and structs are two
    completely different things.
    for example:

    struct Foo{};
    Foo* p_foo = new Foo;

    The above pointer, when dereferenced, accesses a whole Foo object.
    You cannot do this with an array. An array can be created in the following
    ways:

    Foo* p_arr = new Foo[64];
    Foo arr[64];

    There is no way to access either array, as a whole. The underlying
    techincalities of a computer system do not allow us to directly access an
    array , as a whole.




    >> >> > Perhaps unfortunate, but that's life. And when
    >> >> > you go to the next point in the C FAQ (6.3 instead of 6.2)
    >> >> >
    >> >> > http://c-faq.com/aryptr/aryptrequiv.html
    >> >> >
    >> >> > you will find that it then goes into greater detail, explicitly
    >> >> > speaking about the "first element of an array":
    >> >> >
    >> >> Yes and there is nothing wrong with being specific about what element
    >> >> a
    >> >> pointer points to. But there is something wrong if you treat the
    >> >> pointer
    >> >> as
    >> >> if it ONLY points to that element, and is not also a pointer to the
    >> >> array.
    >> >
    >> > Again, an array is a completely different beast from an
    >> > element of it. These are two different types.

    >
    >> An array of chars is not a type, its an entity.

    >
    > I never said that an array of chars "is" a type, I said
    > it "has" a type - beside its property of consisting of a
    > number of bytes.


    An array of chars has the type char. Look at the declaration:

    char arr[16];

    The type is char.
    You seem to think the type is some fancy array-type, its not.




    >We're not discussing assembler here, the
    > language adds types to entities when we progrm in that
    > language and we need to consider that. What later happens
    > at the execution phase is something different. There is no
    > 1-to-1 mappin between the language and what the processor
    > does when the program has been compiled. Otherwise using a
    > computer language would be useless.
    >
    >> > And a pointer
    >> > can only have a single type, the type it was created with.
    >> > So a pointer to char is not a pointer to an array of chars,
    >> > it remains a pointer to char whereever you make it point to.
    >> > Just because you store the address of the first element of
    >> > an array in it, which has the same address as the array it-
    >> > self, does not make it a pointer to the array.
    >> >

    >> A pointer of type char* can point to an array of chars, when dereferenced
    >> it
    >> returns one element of the array.
    >> You cannot get any pointer type that addresses a whole array
    >> simultaneously,
    >> unless the array is sized one or something silly like that.

    >
    >> > A pointer does not only have a value but also has a type.
    >> > That two pointer of different types have the same value does
    >> > not make them equal.

    >> This depends on what you mean by being equal.
    >> are the following two variables equal:
    >> int x=0
    >> char c=0;

    >
    > No, they aren't, see above.
    >

    As I said it depends on what you mean by equal,
    Mathematically x and c both contain the value zero, they are equal in that
    sense.

    >> > Perhaps you have spent a long time doing assembler program-
    >> > ming. There, if two addresses are the same that's all you
    >> > care about. But when you go to a languages with a type
    >> > system things are different. It isn't just about memory
    >> > addresses anymore. Suddenly, two addresses being the same
    >> > isn't all there is since pointers with different types also
    >> > have different properties, like different behaviour when
    >> > being incremented. They add a new meaning that can't be
    >> > expressed in terms of just their values. A lot of things
    >> > become simpler but at the cost of having to think in two
    >> > and not just one "dimension" - value and type instead of
    >> > just value.
    >> >

    >> Yes there is obviously a difference in opinions on this. I think neither
    >> POV
    >> can be said to be right or wrong.

    >
    > I don't think so. I feel that you're missing an important
    > point, i.e. that a computer language is more than just
    > about bits and bytes. It adds completely new levels of mea-
    > ning that can't be understood in terms of what happpens at
    > the register and memory level. This allow you to get away
    > from thinking just in categories of bytes and what happens
    > to them and instead lets you concentrate on the problem do-
    > main. Like, when you write "car->turn( 30 );" in an OOP
    > program you aren't supposed to keep in mind what that does
    > in terms of what happens in the CPU, you should keep focused
    > on what the class 'car' is an instance of will do with that.
    >


    >> But having this acceptance for others' POV I feel its wrong to suggest
    >> one
    >> POV is sloppy and somehow incorrect when it's a failure to understand the
    >> other POV.

    >
    > You're in a good mood tonight;-) But, sorry, I think your
    > POV is wrong, or at least misses an important aspect.
    >


    Oh well I thought I was letting you of the hook by accepting you POV but
    obviously this gesture of good will has backfired on me :)

    >> >> > | A reference to an object of type array-of-T which appears
    >> >> > | in an expression decays (with three exceptions) into a pointer
    >> >> > | to its first element; the type of the resultant pointer is
    >> >> > | pointer-to-T.
    >> >> >
    >> >> > The word "decays" seems to be at the heart of many misunder-
    >> >> > standings: this is a conversion the compiler does under cer-
    >> >> > tain circumstances but does not imply equality.
    >> >> >
    >> >> The term decays is used , becasue an array has typeinfo which is lost
    >> >> when
    >> >> its converted to a pointer.
    >> >
    >> > Yes, and because that loss of information would not happen
    >> > when you go from an array-of-T to an pointer-to-array-of-T.
    >> > The type array-to-T e.g. "knows" abouth the number of ele-
    >> > ments, as does the type pointer-to-array-of-T, while the
    >> > type pointer-to-T has no notion at all of something like
    >> > "numbers of elements" - there are no elements, just a
    >> > pointer to a single instance of T.
    >> >

    >> But sometimes you don't need the type info.
    >> And often you have no option because you are using a function that takes
    >> a
    >> pointer to an array , not a reference.

    >
    > But regardles if I want the type or not it's there, given by the
    > language I'm using.
    >

    Yes but you don't seem to think an array has some magical type, for example:

    char arr1[12];
    int arr2[12];

    The above arrays have the types char and int respectively. There is no
    magical type.


    >> Perhaps it would be better if C++ pointers to array were of the type you
    >> describe but this is not the case , I think we are stuck with the present
    >> case which we inhereted from C

    >
    > I'm not really religious about the way it's done in C or C++.
    > And passing a pointer to an array would require other changes
    > in the language. Since an array has a well-defined length you
    > would need a functions for each length of array. To avoid
    > that You would need to change C++ so that it would accept an
    > argument of 'pointer to array of unspecified length' but still
    > be able to get at the length - or you'd be back to square one,
    > i.e. you'd would have to pass a length with the pointer to the
    > array. And when we would need that then it would make no sense
    > at all, there would hardly any difference to what we have now.
    >
    >> >> >> >> char* p= new char[64];
    >> >> >> >> The above is a pointer points to an array of 64 chars.
    >> >> >> >
    >> >> >> > No, that's a pointer to a single char, the one at the
    >> >> >> > very start of the array. If you want a pointer to an
    >> >> >> > array of 64 chars you need
    >> >> >> >
    >> >> >> > char (*p64)[64];
    >> >> >> >
    >> >> >> Ok so this is also wrong?
    >> >> >> <quote ref=http://www2.research.att.com/~bs/glossary.html>
    >> >> >> "char* - pointer to a char or an array of char."
    >> >> >> </quote>
    >> >> >
    >> >> > Again lingo, not wrong when meant in the right way, just a
    >> >> > bit sloppily expressed. It might have been better if he had
    >> >> > said "...or the first element of an array", but then this is
    >> >> > a glossary, not an in-depth explanation.
    >> >> >
    >> >> Again why would he say pointer the nth element, when the pointer can
    >> >> point
    >> >> to any element?
    >> >
    >> >> >> > It's really simple: If you increment a pointer by 1 it
    >> >> >> > always points to the address directly behind the object
    >> >> >> > it pointed to (its value is increased by the size of the
    >> >> >> > type of object it points to). And if you incrememt 'p'
    >> >> >> > by 1 it points to the next char in the array, so it's a
    >> >> >> > pointer to a single char, not an array of so many chars.
    >> >> >> > That it points to the first element of the array doesn't
    >> >> >> > change anything about that. But if you increment 'p64' by
    >> >> >> > 1 it points directly past the end of the array, so that's
    >> >> >> > a pointer to an array of 64 chars.
    >> >> >> >
    >> >> >> > Perhaps you should read Chris Torek's nice article about
    >> >> >> > pointers and arrays
    >> >> >> >
    >> >> >> > http://web.torek.net/torek/c/pa.html
    >> >> >> >
    >> >> >> > and also
    >> >> >> >
    >> >> >> > http://web.torek.net/torek/c/expr.html#therule
    >> >> >> >
    >> >> >> > (which might address the reasons behind your confusion).
    >> >> >> > While it's about C C++ works the same way.
    >> >> >> >
    >> >> >> Thanks for your post but I think you should read the quotes I
    >> >> >> posted
    >> >> >> above
    >> >> >> from Bjarbne Stroustrup and Steve Summit.
    >> >> >
    >> >> > I did but I don't think they really support your point of view.
    >> >> >
    >> >> \They clearly state exactly my POV.
    >> >> That a char* can point to a single char or an array of chars.
    >> >
    >> > Why then does incrementing pointers of different types re-
    >> > sult in different values? You seem to be avoiding that point.
    >> > Or you're using your private definition of "pointer", probably
    >> > one that turns a blind eye to pointers having a type beside a
    >> > value. That's nothing I'm going to have sleepness nights about,
    >> > but it makes discussions a bit difficult and, if you insist on
    >> > your definition, futile in the longer (or even shorter) run.
    >> >

    >> I don't see that I'm avoiding anything.
    >> You ask why does incremeenting pointers of different types result in
    >> different values.

    >
    >> I think you mean by different values , you probably mean different
    >> stepping
    >> increments and not the value of the pointer.

    >
    > The values of the two pointers 'p' and 'p64'
    >
    > char x[ 64 ];
    > char *p = x;
    > char ( *p64 )[ 64 ] = &x;
    >
    > are the same now but will definitely be different after you did
    >
    > p++;
    > p64++;
    >
    > The first one will point to the second element of the array 'x',
    > the other will point directly after the end of 'x'. So I would
    > call that a different value, wouldn't you? And that's one of
    > the differences in behaviour that's due to the different types
    > of the pointers.
    >

    p64 is the wrong type, it has an extra level of indirection.
    The pointed to array is an array of chars, not a array of char[64].



    >> The way I see it an array is converted to a pointer of type pointer to
    >> (n-1)
    >> dimensional array. So with a 2dim array the pointer-type it's converted
    >> to
    >> is:
    >> T (*)[Dim2]

    >
    >> incrementing this pointer-type would result in stepping increments
    >> sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
    >> allows the following 2d subscripting with 2d array pointers:
    >> p[0][0];

    >
    > Nice point you're giving me there;-) If you have e.g.
    >
    > int a[ 3 ][ 5 ];
    >
    > then you need
    >
    > int ( *ap )[ 5 ] = a;
    >
    > i.e. 'a' "decays" to a real 1D array pointer like the one I des-
    > cribed before. And are you now going to argue that '(*ap)[5]' is
    > a pointer to a two-dimensional array as it would seem logical to
    > me when you claim that 'char *' is also a pointer to an array?
    >
    > To me it looks like a pointer to a 1-dimensional array as this
    > example program perhaps can illustrate
    >
    > #include <iostream>
    > int main( )
    > {
    > int a[ 3 ] = { 1, 2, 3 };
    > int ( *ap )[ 3 ] = &a;

    The above is a pointer derivation. You are creating another level of
    indirection.
    'a' is converted to a pointer and you take the address of it. 'ap' is
    basically a pointer to a pointer.


    > int b[ 3 ][ 2 ] = { { 7, 9,}, { -4, 5,}, { 8, -5 } };
    > int ( *bp )[ 2 ] = b;
    > std::cout << ( *ap )[ 1 ] << ' ' << ( *bp )[ 1 ] << '\n';
    > }
    >
    > - both 'ap' and 'bp' seem to me to have the same type.
    >

    no one is int(*)[3] and the other is int(*)[2].

    > As you say, this conversion ("decaying" when an array is used
    > in a context where a value is expected) reduces the dimension
    > by 1. But that does not make the thing on the left and right
    > hand side the same - the equal sign is even more out of place
    > here then it is everywhere else (when you consider its mathe-
    > matical meaning). This is basically an overloding of the '='
    > operator to get any sense out of that expression since an
    > array (whatever it's dimension) simply has no value in C or
    > C++ and thus such an expression would be meaningless other-
    > wise. (Or arrays would have to be made "first-class" citi-
    > zens of C and C++, so that you could assign one array to
    > another with '=' and pass it by value to a function, as you
    > can do with structures or class instances.)
    >
    > --
    > \ Jens Thoms Toerring ___
    > \__________________________ http://toerring.de
    >
     
    Paul, Apr 19, 2011
    #19
  20. Paul <> wrote:
    > The type of an array is that of the objects it contains, for exmaple:


    > float arr[16];


    > The type is float, you just asked the compiler to make 16 of them in
    > sequnece.


    No, that's simply wrong. The newly created object 'arr' has
    the type 'array-of-16-floats' and not 'float'. If we can't
    even agree on something that simple and obvious we can stop
    here since we will never get any further.

    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, 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,802
    Keith Thompson
    Sep 27, 2005
  2. Replies:
    4
    Views:
    792
  3. Syron
    Replies:
    1
    Views:
    533
  4. , India

    pointer to an array vs pointer to pointer

    , India, Sep 20, 2011, in forum: C Programming
    Replies:
    5
    Views:
    467
    James Kuyper
    Sep 23, 2011
  5. Francois Grieu

    Is pointer arithmetic within a struct well defined?

    Francois Grieu, Nov 29, 2013, in forum: C Programming
    Replies:
    23
    Views:
    300
    Seebs
    Dec 4, 2013
Loading...

Share This Page