Your view of FAQ section.

Discussion in 'C Programming' started by Richard, Jun 3, 2007.

  1. Richard

    Richard Guest

    One of the most repeatedly given pointers is to

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

    which discusses pointers and arrays and the subtle differences between

    char a[] = "hello";
    char *p = "world";

    Now, my question is this - how do you feel about the way the FAQ
    describes the compiler working. We already now that pointers and arrays
    may or may not compile differently and may or may not be more efficient
    than each other depending on target HW.

    But should the FAQ really go into detail about how the compiler
    calculates element addresses?

    e.g

    ,----
    | It is useful to realize that a reference like x[3] generates different code depending on whether x is an array or a pointer. Given the declarations above, when the compiler
    | sees the expression a[3], it emits code to start at the location ``a'', move three past it, and fetch the character there. When it sees the expression p[3], it emits code to
    | start at the location ``p'', fetch the pointer value there, add three to the pointer, and finally fetch the character pointed to. In other words, a[3] is three places past
    | (the start of) the object named a, while p[3] is three places past the object pointed to by p. In the example above, both a[3] and p[3] happen to be the character 'l', but
    | the compiler gets there differently. (The essential difference is that the values of an array like a and a pointer like p are computed differently whenever they appear in
    | expressions, whether or not they are being subscripted, as explained further in question 6.3.) See also question 1.32.
    `----
     
    Richard, Jun 3, 2007
    #1
    1. Advertising

  2. Richard <> writes:
    > One of the most repeatedly given pointers is to
    >
    > http://c-faq.com/aryptr/aryptr2.html
    >
    > which discusses pointers and arrays and the subtle differences between
    >
    > char a[] = "hello";
    > char *p = "world";
    >
    > Now, my question is this - how do you feel about the way the FAQ
    > describes the compiler working. We already now that pointers and arrays
    > may or may not compile differently and may or may not be more efficient
    > than each other depending on target HW.
    >
    > But should the FAQ really go into detail about how the compiler
    > calculates element addresses?


    Yes.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 3, 2007
    #2
    1. Advertising

  3. Richard

    Richard Guest

    Keith Thompson <> writes:

    > Richard <> writes:
    >> One of the most repeatedly given pointers is to
    >>
    >> http://c-faq.com/aryptr/aryptr2.html
    >>
    >> which discusses pointers and arrays and the subtle differences between
    >>
    >> char a[] = "hello";
    >> char *p = "world";
    >>
    >> Now, my question is this - how do you feel about the way the FAQ
    >> describes the compiler working. We already now that pointers and arrays
    >> may or may not compile differently and may or may not be more efficient
    >> than each other depending on target HW.
    >>
    >> But should the FAQ really go into detail about how the compiler
    >> calculates element addresses?

    >
    > Yes.


    Can you explain why?

    Does the standard stipulate how the compiler must generate the addresses?
     
    Richard, Jun 3, 2007
    #3
  4. Richard <> writes:
    > Keith Thompson <> writes:
    >> Richard <> writes:
    >>> One of the most repeatedly given pointers is to
    >>>
    >>> http://c-faq.com/aryptr/aryptr2.html
    >>>
    >>> which discusses pointers and arrays and the subtle differences between
    >>>
    >>> char a[] = "hello";
    >>> char *p = "world";
    >>>
    >>> Now, my question is this - how do you feel about the way the FAQ
    >>> describes the compiler working. We already now that pointers and arrays
    >>> may or may not compile differently and may or may not be more efficient
    >>> than each other depending on target HW.
    >>>
    >>> But should the FAQ really go into detail about how the compiler
    >>> calculates element addresses?

    >>
    >> Yes.

    >
    > Can you explain why?
    >
    > Does the standard stipulate how the compiler must generate the addresses?


    Ok, that was overly terse. But the FAQ doesn't really talk about
    generated code; it's more of a description of what happens in the
    abstract machine, which is important to an understanding of what the
    code actually means.

    Do you have a better way to describe the difference between a[3] and
    p[3] (where a is an array object and p is a pointer object)?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 3, 2007
    #4
  5. "Keith Thompson" <> wrote in message
    news:...
    > Richard <> writes:
    >> Keith Thompson <> writes:
    >>> Richard <> writes:
    >>>> One of the most repeatedly given pointers is to
    >>>>
    >>>> http://c-faq.com/aryptr/aryptr2.html
    >>>>
    >>>> which discusses pointers and arrays and the subtle differences between
    >>>>
    >>>> char a[] = "hello";
    >>>> char *p = "world";
    >>>>
    >>>> Now, my question is this - how do you feel about the way the FAQ
    >>>> describes the compiler working. We already now that pointers and arrays
    >>>> may or may not compile differently and may or may not be more efficient
    >>>> than each other depending on target HW.
    >>>>
    >>>> But should the FAQ really go into detail about how the compiler
    >>>> calculates element addresses?
    >>>
    >>> Yes.

    >>
    >> Can you explain why?
    >>
    >> Does the standard stipulate how the compiler must generate the addresses?

    >
    > Ok, that was overly terse. But the FAQ doesn't really talk about
    > generated code; it's more of a description of what happens in the
    > abstract machine, which is important to an understanding of what the
    > code actually means.
    >
    > Do you have a better way to describe the difference between a[3] and
    > p[3] (where a is an array object and p is a pointer object)?
    >

    Exactly. People are looking for an explanation, not a definition. Sometimes
    it is better to say something which is slightly inaccurate, or only
    represents the general case, but is concrete, rather than give the latter of
    the law.

    Array - pointer equivalance is a classic case. Unless you go through a
    stage of thinking that arrays and pointers are equivalent, you will never
    understand why they are not equivalent.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Jun 3, 2007
    #5
  6. Richard

    Richard Guest

    Keith Thompson <> writes:

    > Richard <> writes:
    >> Keith Thompson <> writes:
    >>> Richard <> writes:
    >>>> One of the most repeatedly given pointers is to
    >>>>
    >>>> http://c-faq.com/aryptr/aryptr2.html
    >>>>
    >>>> which discusses pointers and arrays and the subtle differences between
    >>>>
    >>>> char a[] = "hello";
    >>>> char *p = "world";
    >>>>
    >>>> Now, my question is this - how do you feel about the way the FAQ
    >>>> describes the compiler working. We already now that pointers and arrays
    >>>> may or may not compile differently and may or may not be more efficient
    >>>> than each other depending on target HW.
    >>>>
    >>>> But should the FAQ really go into detail about how the compiler
    >>>> calculates element addresses?
    >>>
    >>> Yes.

    >>
    >> Can you explain why?
    >>
    >> Does the standard stipulate how the compiler must generate the addresses?

    >
    > Ok, that was overly terse. But the FAQ doesn't really talk about
    > generated code; it's more of a description of what happens in the
    > abstract machine, which is important to an understanding of what the
    > code actually means.
    >
    > Do you have a better way to describe the difference between a[3] and
    > p[3] (where a is an array object and p is a pointer object)?


    No. But telling us how the compiler may or may not do it is overly
    presumptuous IMO.

    Only a while ago I was sure (as stated in K&R2 too btw) that using
    pointers and not arrays generated faster code as a general rule. Some
    work I have done since has pretty much made me change my mind.
     
    Richard, Jun 3, 2007
    #6
  7. Richard

    Eric Sosman Guest

    Richard wrote:
    > Keith Thompson <> writes:
    >>
    >> Do you have a better way to describe the difference between a[3] and
    >> p[3] (where a is an array object and p is a pointer object)?

    >
    > No. But telling us how the compiler may or may not do it is overly
    > presumptuous IMO.


    The goal of the FAQ is explanation, not specification.
    As such, it quite frequently ventures outside the territory
    marked off by the Standard -- for example, it talks not only
    about "undefined behavior" but also about "segmentation
    violation" and "general protection fault." I see nothing
    amiss with the FAQ speaking about generated code (which itself
    is beyond the scope of the Standard) to highlight a point and
    bring the reader closer to the "Aha!" moment.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jun 3, 2007
    #7
  8. Richard

    Flash Gordon Guest

    Malcolm McLean wrote, On 03/06/07 10:17:
    >
    > "Keith Thompson" <> wrote in message


    <snip>

    >> Do you have a better way to describe the difference between a[3] and
    >> p[3] (where a is an array object and p is a pointer object)?
    >>

    > Exactly. People are looking for an explanation, not a definition.
    > Sometimes it is better to say something which is slightly inaccurate, or
    > only represents the general case, but is concrete, rather than give the
    > latter of the law.


    To an extent, yes.

    > Array - pointer equivalance is a classic case. Unless you go through a
    > stage of thinking that arrays and pointers are equivalent, you will
    > never understand why they are not equivalent.


    However here I completely disagree.

    I can't remember ever thinking that arrays and pointers were equivalent,
    and I can see no reason why someone would need to believe that
    particular fallacy before understanding why it is false. Explain one
    concept in one lesson, make sure it is understood, explain the other
    concept in another lesson and make sure it is understood, and then
    explain that because of the way C implements arrays you don't pass
    arrays and when you can treat one as the other.
    --
    Flash Gordon
     
    Flash Gordon, Jun 3, 2007
    #8
  9. "Malcolm McLean" <> writes:
    [...]
    > Array - pointer equivalance is a classic case. Unless you go through a
    > stage of thinking that arrays and pointers are equivalent, you will
    > never understand why they are not equivalent.


    Either I don't understand that statement, or I completely disagree
    with it; I'm not sure which.

    Surely it's possible for someone learning C to understand from the
    beginning that arrays and pointers are very different things, if the
    concepts are just explained correctly on the first exposure.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 3, 2007
    #9
  10. Richard

    Chris Dollin Guest

    Malcolm McLean wrote:

    > Array - pointer equivalance is a classic case. Unless you go through a
    > stage of thinking that arrays and pointers are equivalent, you will never
    > understand why they are not equivalent.


    I don't think I ever went through the stage of believing that they
    were equivalent, but I claim I understand why they are not.

    Of course, C wasn't my first language -- it wasn't even my fourth --
    and I hacked BCPL before I ever met C in real life.

    --
    "Anything can happen in the next half-hour." /Stingray/

    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
     
    Chris Dollin, Jun 4, 2007
    #10
  11. "Keith Thompson" <> wrote in message
    news:...
    > "Malcolm McLean" <> writes:
    > [...]
    >> Array - pointer equivalance is a classic case. Unless you go through a
    >> stage of thinking that arrays and pointers are equivalent, you will
    >> never understand why they are not equivalent.

    >
    > Either I don't understand that statement, or I completely disagree
    > with it; I'm not sure which.
    >
    > Surely it's possible for someone learning C to understand from the
    > beginning that arrays and pointers are very different things, if the
    > concepts are just explained correctly on the first exposure.
    >

    You've got an unusual mind. Which is probably a strength, as a programmer.
    However most people think and learn in far less abstract way.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Jun 7, 2007
    #11
  12. "Malcolm McLean" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> "Malcolm McLean" <> writes:
    >> [...]
    >>> Array - pointer equivalance is a classic case. Unless you go through a
    >>> stage of thinking that arrays and pointers are equivalent, you will
    >>> never understand why they are not equivalent.

    >>
    >> Either I don't understand that statement, or I completely disagree
    >> with it; I'm not sure which.
    >>
    >> Surely it's possible for someone learning C to understand from the
    >> beginning that arrays and pointers are very different things, if the
    >> concepts are just explained correctly on the first exposure.
    >>

    > You've got an unusual mind. Which is probably a strength, as a
    > programmer. However most people think and learn in far less abstract
    > way.


    I still disagree. I think most people are perfectly capable of
    understanding C pointers and arrays without *ever* having the delusion
    that they're the same thing. And anyone who's not capable of that
    likely will never really understand either arrays or pointers.

    (I'm not saying that anyone who has thought arrays and pointers are
    the same thing can never understand them. The misconception is
    unnecessary, not fatal.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 7, 2007
    #12
  13. Richard

    Flash Gordon Guest

    Keith Thompson wrote, On 07/06/07 08:02:
    > "Malcolm McLean" <> writes:
    >> "Keith Thompson" <> wrote in message
    >> news:...
    >>> "Malcolm McLean" <> writes:
    >>> [...]
    >>>> Array - pointer equivalance is a classic case. Unless you go through a
    >>>> stage of thinking that arrays and pointers are equivalent, you will
    >>>> never understand why they are not equivalent.
    >>> Either I don't understand that statement, or I completely disagree
    >>> with it; I'm not sure which.
    >>>
    >>> Surely it's possible for someone learning C to understand from the
    >>> beginning that arrays and pointers are very different things, if the
    >>> concepts are just explained correctly on the first exposure.
    >>>

    >> You've got an unusual mind. Which is probably a strength, as a
    >> programmer. However most people think and learn in far less abstract
    >> way.

    >
    > I still disagree. I think most people are perfectly capable of
    > understanding C pointers and arrays without *ever* having the delusion
    > that they're the same thing. And anyone who's not capable of that
    > likely will never really understand either arrays or pointers.


    I agree. I've managed to explain the concepts of arrays and pointer to
    people who have NO programming experience. It is really very easy to
    explain in a classroom.

    Desks are arranged in a traditional way in the classroom. OK, here is a
    2 dimensional array of desks. We will number the rows from 0, and the
    columns from 0, so John is in desk[3][5].

    Now for pointers. My finger is pointing to desk[3][5], now I'm going to
    increment it, it is now pointing at desk[3][6] where Jenny is.

    Simple. Then, once they understand the general concepts of arrays and
    pointers you can go on to explain the wrinkles of array in C.

    As I say, I know that this type of explanation works (possibly with a
    bit more discussion) since I've used it with non-computer people and
    managed to go on to explain why things are not working in buggy programs.

    > (I'm not saying that anyone who has thought arrays and pointers are
    > the same thing can never understand them. The misconception is
    > unnecessary, not fatal.)


    Agreed.
    --
    Flash Gordon
     
    Flash Gordon, Jun 7, 2007
    #13
    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. jimjim
    Replies:
    10
    Views:
    527
    Alf P. Steinbach
    Sep 14, 2005
  2. Diego Martins

    issue on parashift faq section [39.14]

    Diego Martins, Sep 5, 2007, in forum: C++
    Replies:
    3
    Views:
    382
    James Kanze
    Sep 6, 2007
  3. Replies:
    0
    Views:
    166
  4. Parthiv Joshi
    Replies:
    1
    Views:
    692
    Samuel L Matzen
    Jul 6, 2004
  5. kampy
    Replies:
    9
    Views:
    336
    Steven D'Aprano
    Oct 19, 2012
Loading...

Share This Page