Why do so few people know the difference between arrays and pointers.

Discussion in 'C Programming' started by Me, Jun 8, 2004.

  1. Me

    Me Guest

    Just a question/observation out of frustration.

    I read in depth the book by Peter Van Der Linden entitled
    "Expert C Programming" (Deep C Secrets). In particular the
    chapters entitled:
    4: The Shocking Truth: C Arrays and Pointers Are NOT the Same!
    9: More about Arrays
    10: More about Pointers

    What blows me out of the water is the fact that 'every' programmer
    comming out of college that I've interviewed thinks that pointers
    and arrays are the same thing.

    They go so far as to tell me that, in the following code, 'arr' is
    a pointer to an array of integers. Or they tell me that 'arr' is a
    pointer to an 'int'. When this is not the case at all.

    int arr[100];

    The variable 'arr' IS and array of 100 integers...THATS ITS TYPE MAN.
    Just like the TYPE of 'i' in the following is 'int'.

    int i;

    and the type of 'ch' in the following is 'char *'.

    char *ch = "string";

    The TYPE of 'arr' above is 'an array of 100 integers'. That's WHY you
    have to declare a pointer to it as follows:

    int (*p)[100];

    p = &arr; // Valid
    p = arr; // Invalid (compiler will warn you) but works because the
    address happens to be the same.

    Note: When you use an array in an expression or as an R-Value, the result
    of the
    operation yields a pointer to the first element in the array. Thus:

    int *ip = arr; // Valid: arr turns into an int pointer (a pointer to the
    first element in the array)
    // Not because ip is an 'int *' be because the array 'arr' is being
    used in an expression
    // as an R-Value.

    Man the C teachers in college aren't doing their job!



    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
    Me, Jun 8, 2004
    #1
    1. Advertising

  2. Me

    Malcolm Guest

    "Me" <> wrote in message
    >
    > " The Shocking Truth: C Arrays and Pointers Are NOT the
    > Same!
    >

    Array labels decay to pointers, so

    void foo(int *ptr);

    void bar(void)
    {
    int arr[100];

    foo(arr);
    }

    calls foo with a pointer to an array of integers.

    This ia all you need to know about C array pointer equivalence.

    If you start using multi-dimensional arrays and fancy declarations you
    deserve all that is coming to you.
    Malcolm, Jun 8, 2004
    #2
    1. Advertising

  3. Troll Alert: Why do so few people know the difference between arraysand pointers.

    Something that calls itself Me wrote:

    > Just a question/observation out of frustration.
    >
    > I read in depth the book by Peter Van Der Linden entitled
    > "Expert C Programming" (Deep C Secrets).
    > In particular the chapters entitled:
    > 4: The Shocking Truth: C Arrays and Pointers Are NOT the Same!
    > 9: More about Arrays
    > 10: More about Pointers


    Obvious hyperbole.

    > What blows me out of the water is the fact that
    > 'every' programmer comming out of college that I've interviewed
    > thinks that pointers and arrays are the same thing.
    >
    > They go so far as to tell me that, in the following code,
    > 'arr' is a pointer to an array of integers.
    > Or they tell me that 'arr' is a pointer to an 'int'.
    > When this is not the case at all.
    >
    > int arr[100];
    >
    > The variable 'arr' IS and array of 100 integers...THATS ITS TYPE MAN.
    > Just like the TYPE of 'i' in the following is 'int'.
    >
    > int i;
    >
    > and the type of 'ch' in the following is 'char*'.
    >
    > char* ch = "string";
    >
    > The TYPE of 'arr' above is 'an array of 100 integers'.
    > That's WHY you have to declare a pointer to it as follows:
    >
    > int (*p)[100];
    >
    > p = &arr; // Valid
    > p = arr; // Invalid (compiler will warn you)
    > // but works because the address happens to be the same.
    >
    > Note: When you use an array in an expression or as an R-Value,
    > the result of the operation
    > yields a pointer to the first element in the array. Thus:
    >
    > int* ip = arr; // Valid: arr turns into an int pointer
    > // (a pointer to the first element in the array)
    > // Not because ip is an 'int *'
    > // but because the array 'arr' is being used
    > // in an expression as an R-Value.
    >
    > Man the C teachers in college aren't doing their job!


    Do you feel better now that you got that off your chest?
    E. Robert Tisdale, Jun 8, 2004
    #3
  4. Me

    Me Guest

    On Tue, 8 Jun 2004 22:30:49 +0100, Malcolm
    <> wrote:

    > "Me" <> wrote in message
    >>
    >> " The Shocking Truth: C Arrays and Pointers Are NOT the
    >> Same!
    >>

    > Array labels decay to pointers, so
    >
    > void foo(int *ptr);
    >
    > void bar(void)
    > {
    > int arr[100];
    >
    > foo(arr);
    > }
    >
    > calls foo with a pointer to an array of integers.


    Actually you are mistaken...probably you just mis-typed.

    It calls foo with a pointer to an int.... not a pointer to an array of
    ints.
    It just so happens that what the pointer is pointing to is the first int in
    the allocated array of 100 ints, but 'foo' doesn't know that. foo() just
    thinks
    it is an 'int' pointer.

    >
    > This ia all you need to know about C array pointer equivalence.
    >
    > If you start using multi-dimensional arrays and fancy declarations you
    > deserve all that is coming to you.
    >
    >




    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
    Me, Jun 8, 2004
    #4
  5. Me wrote:
    >
    >
    > Malcolm wrote:
    >
    >> Array labels decay to pointers, so
    >>
    >> void foo(int *ptr);
    >>
    >> void bar(void) {
    >> int arr[100];
    >> foo(arr);
    >> }
    >>
    >> calls foo with a pointer to an array of integers.

    >
    > Actually you are mistaken...probably you just mis-typed.
    >
    > It calls foo with a pointer to an int....
    > not a pointer to an array of ints.


    Correct.

    > It just so happens that what the pointer is pointing to
    > is the first int in the allocated array of 100 ints,


    I'm pretty sure that you don't mean to imply that
    it is just an accident that arr is converted
    into a pointer to the first element of arr.

    > but 'foo' doesn't know that.
    > foo() thinks [that] it is just an 'int' pointer.
    E. Robert Tisdale, Jun 9, 2004
    #5
  6. Me

    CBFalconer Guest

    Re: Why do so few people know the difference between arrays andpointers.

    Me wrote:
    >

    .... snip ...
    >
    > What blows me out of the water is the fact that 'every' programmer
    > comming out of college that I've interviewed thinks that pointers
    > and arrays are the same thing.


    When I got out of college in nineteen-<mumble> I certainly didn't
    think so. :)

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    CBFalconer, Jun 9, 2004
    #6
  7. "Me" <> wrote in message
    news:eek:...
    >
    > Just a question/observation out of frustration.
    >
    > I read in depth the book by Peter Van Der Linden entitled
    > "Expert C Programming" (Deep C Secrets). In particular the
    > chapters entitled:
    > 4: The Shocking Truth: C Arrays and Pointers Are NOT the Same!
    > 9: More about Arrays
    > 10: More about Pointers
    >
    > What blows me out of the water is the fact that 'every' programmer
    > comming out of college that I've interviewed thinks that pointers
    > and arrays are the same thing.
    >
    > They go so far as to tell me that, in the following code, 'arr' is
    > a pointer to an array of integers. Or they tell me that 'arr' is a
    > pointer to an 'int'. When this is not the case at all.
    >
    > int arr[100];
    >
    > The variable 'arr' IS and array of 100 integers...THATS ITS TYPE MAN.
    > Just like the TYPE of 'i' in the following is 'int'.
    >
    > int i;
    >
    > and the type of 'ch' in the following is 'char *'.
    >
    > char *ch = "string";
    >
    > The TYPE of 'arr' above is 'an array of 100 integers'. That's WHY you
    > have to declare a pointer to it as follows:
    >
    > int (*p)[100];
    >
    > p = &arr; // Valid
    > p = arr; // Invalid (compiler will warn you) but works because the
    > address happens to be the same.
    >
    > Note: When you use an array in an expression or as an R-Value, the result
    > of the
    > operation yields a pointer to the first element in the array. Thus:
    >
    > int *ip = arr; // Valid: arr turns into an int pointer (a pointer to the
    > first element in the array)
    > // Not because ip is an 'int *' be because the array 'arr' is being
    > used in an expression
    > // as an R-Value.
    >
    > Man the C teachers in college aren't doing their job!


    I'm currently teaching my self C from books and the internet and when I
    first started learning, constant mentions of the "equivalence" of arrays and
    pointers confused the hell out of me because based on what I understood
    (correctly) about pointers and arrays, there is nothing equivalent about
    them, they're completely different although related things. What would have
    saved me a bunch of headscratching would be definitions of an array and a
    pointer and then statements of the following facts:

    An array, when referenced without an element number decays into a pointer to
    that array's first element (without needing to use the & operator)

    #include <stdio.h>
    int main (void) {
    int foo[10];
    int *bar;
    bar = foo;
    printf("%i",bar[1]); /* is equivalent to the following */
    printf("%i",*(bar+1)); /* both will output the contents of foo[1] */
    return 0;
    }

    Based on a understanding of pointers and arrays, this explains all that
    needs to be explained without using the words "arrays and pointers are
    equivalent" or similar which I've seen in several places and are just
    blatantly wrong.

    Excuse me and please do correct me if I've used any incorrect terminology
    here, as I said, I'm still learning.

    >
    >
    >
    > --
    > Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
    Kieran Simkin, Jun 9, 2004
    #7
  8. Me

    Daniel Rudy Guest

    And somewhere around the time of 06/08/2004 14:10, the world stopped and
    listened as Me contributed the following to humanity:

    > Just a question/observation out of frustration.
    >
    > I read in depth the book by Peter Van Der Linden entitled
    > "Expert C Programming" (Deep C Secrets). In particular the
    > chapters entitled:
    > 4: The Shocking Truth: C Arrays and Pointers Are NOT the Same!
    > 9: More about Arrays
    > 10: More about Pointers
    >
    > What blows me out of the water is the fact that 'every' programmer
    > comming out of college that I've interviewed thinks that pointers
    > and arrays are the same thing.
    >


    Yes and no. An array is a list of data of some type. A pointer is a
    reference that points to some data in memory.

    Internally, the array identifier acting as the base address, coupled
    with the index * data size, generates a pointer to that data element in
    memory. All of this is internal to the compiler/linker and is usually
    transparent to the programmer, at least that's what my expeiriance has been.

    --
    Daniel Rudy

    Email address has been encoded to reduce spam.
    Remove all numbers, then remove invalid, email, no, and spam to reply.
    Daniel Rudy, Jun 9, 2004
    #8
  9. Me

    Mike Wahler Guest

    "Malcolm" <> wrote in message
    news:ca5b0d$tse$...
    > "Me" <> wrote in message
    > >
    > > " The Shocking Truth: C Arrays and Pointers Are NOT the
    > > Same!
    > >

    > Array labels decay to pointers, so
    >
    > void foo(int *ptr);
    >
    > void bar(void)
    > {
    > int arr[100];
    >
    > foo(arr);
    > }
    >
    > calls foo with a pointer to an array of integers.


    Wrong. Calls 'foo()' with a pointer to an 'int'.
    (type 'int*'). Pointer-to-int and pointer-to-array-of-ints
    are not the same type.

    int *p; /* pointer to int */
    int (*pa)[100]; /* pointer to array of 100 ints */


    > This ia all you need to know about C array pointer equivalence.


    I don't think one should 'know' incorrect information.
    >
    > If you start using multi-dimensional arrays and fancy declarations you
    > deserve all that is coming to you.


    What's 'wrong' with using multi-dimensional arrays,
    and what will come to me if I use one?

    I won't ask what you consider a 'fancy' declaration.

    -Mike
    Mike Wahler, Jun 9, 2004
    #9
  10. Me

    *a Guest

    hi all; i'm a self-taught C-hobbyst; i want to sing k&r's praises: their
    book was somewhat hard for me, i proceeded slowly, sometimes at the "speed"
    of few pages/week, but it's impossible to confuse pointer with arrays then;
    the problem is C needs a non-superficial study
    *a, Jun 9, 2004
    #10
  11. "Kieran Simkin" <> writes:
    [...]
    > An array, when referenced without an element number decays into a pointer to
    > that array's first element (without needing to use the & operator)


    An array name (an identifer that refers to an array object) decays
    into a pointer to the first element whenever it appears in an
    expression, unless it's the operand of a sizeof or unary "&" operator.

    Note that the decay even occurs in an indexing expression:

    int array_obj[10];
    int x;
    ...
    x = array_obj[5];

    In the assignment, the name "array_obj" decays to a pointer to the
    first element of the array object. The indexing operator takes two
    operands, a pointer and an integer.

    Read section 6 of the C FAQ.

    --
    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.
    Keith Thompson, Jun 9, 2004
    #11
  12. Me

    Michael Mair Guest

    Cheerio,


    > What blows me out of the water is the fact that 'every' programmer
    > comming out of college that I've interviewed thinks that pointers
    > and arrays are the same thing.


    If it helps you feel better: We have a finite element code we are
    working with, written in C, largely undocumented, many thousand lines,
    and are looking for students to work for us.
    We get many applications from so-called software engineering students
    in their final year. Every single interview came to the point that
    they did not "know" any programming language at all while boasting
    knowledge of a multitude. We never ever did even get to the point
    where such "fine details" like the differences between arrays and
    pointers would have played a role. Same thing when we were looking
    for someone doing some things in Matlab for us.
    So, do not tell me about frustration ;-)


    > Man the C teachers in college aren't doing their job!


    Based on my sad experiences, I am at the moment teaching C to
    beginners in order to get someone able to work with us.
    I did never tell anyone that pointers and arrays were equivalent,
    in fact, I only started with "&array[0]" and came up with the "idea"
    of using "array" later on, explained exactly what pointers are,
    what arrays are, how they relate -- nonetheless, "pointer equals array"
    is exactly the sort of idea I see them using in their assignments.
    I try to exorcise it in the next lesson but somehow it sticks. I
    suggested a couple of C books to the students but somehow I never
    caught anyone reading one of them. They just get the cheapest C books
    off Amazon thinking this will do... :-/
    Seeing my efforts having no effect for at least ten percent of my
    students, I can only say: Maybe, the fault is not only in the teachers.

    Another thing is that you have to learn some things entirely by
    yourself. Only after you made a serious mistake or saw the outcome
    of some mistake you will remember it by heart. A friend of mine
    for example needed to find out by himself that a quadratic time
    complexity is _much_ worse than linear time complexity of an
    algorithm - even though he theoretically knew it beforehand.
    Looking at myself and at my colleagues as well, I'd say that every
    year I am still learning quite a lot of things in all the programming
    languages I am using.



    Just my two cents
    Michael
    Michael Mair, Jun 9, 2004
    #12
  13. "Keith Thompson" <> wrote in message news:...
    > "Kieran Simkin" <> writes:
    > [...]
    > > An array, when referenced without an element number decays into a pointer to
    > > that array's first element (without needing to use the & operator)

    >
    > An array name (an identifer that refers to an array object) decays
    > into a pointer to the first element whenever it appears in an
    > expression, unless it's the operand of a sizeof or unary "&" operator.
    >


    .... and when a character string literal is used to initialize an array.


    > Note that the decay even occurs in an indexing expression:
    >
    > int array_obj[10];
    > int x;
    > ...
    > x = array_obj[5];
    >
    > In the assignment, the name "array_obj" decays to a pointer to the
    > first element of the array object. The indexing operator takes two
    > operands, a pointer and an integer.
    >
    > Read section 6 of the C FAQ.
    >
    > --
    > 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.
    Vijay Kumar R Zanvar, Jun 9, 2004
    #13
  14. In article <ca6h4p$elo$-stuttgart.de>,
    Michael Mair <-stuttgart.de> wrote:

    > Another thing is that you have to learn some things entirely by
    > yourself. Only after you made a serious mistake or saw the outcome
    > of some mistake you will remember it by heart. A friend of mine
    > for example needed to find out by himself that a quadratic time
    > complexity is _much_ worse than linear time complexity of an
    > algorithm - even though he theoretically knew it beforehand.
    > Looking at myself and at my colleagues as well, I'd say that every
    > year I am still learning quite a lot of things in all the programming
    > languages I am using.


    In my experience, different people learn in different ways. Some prefer
    to actually try out things because it helps them learning. However,
    trying out things is also useful to check if the theory is really
    correct (I once saw a C++ programmer using the quicksort algorithm, but
    for sorting an array of variable sized items, and the underlying methods
    for changing an item took time O (total size of all items) when changing
    the size of an item. The code was not O (N log N), and it was not fast
    enough (noticable delay in the user interface in non-trivial cases)).

    Also, an algorithm with higher time complexity may be faster than one of
    lower complexity up to a certain size. Consider method A taking (N^(2/3)
    log^2 (N)) nanoseconds, and method B taking N^0.7 nanoseconds. For large
    N, method A is faster. For any problem that can be solved in a billion
    years, method A is slower.
    Christian Bau, Jun 9, 2004
    #14
  15. Michael Mair <-stuttgart.de> writes:
    > > Man the C teachers in college aren't doing their job!

    >
    > Based on my sad experiences, I am at the moment teaching C [...]
    > I suggested a couple of C books to the students but somehow I never
    > caught anyone reading one of them. They just get the cheapest C books
    > off Amazon thinking this will do... :-/ Seeing my efforts having no
    > effect for at least ten percent of my students, I can only say: Maybe,
    > the fault is not only in the teachers.


    I don't think it is only the teachers' fault.

    While being a student at the Computer Engineering & Informatics
    Department here in Patras, Greece, I used to say that about 80% of the
    students who enter my department every year are not interested (and,
    quite probably, they never will be) in learning anything beyond the
    absolutely necessary stuff they have to "put up with" in order to get a
    degree. Only a small number of the remaining 20% has the patience and
    perseverance it takes to learn more about the fine details of
    programming--regardless of the language in question.

    > Another thing is that you have to learn some things entirely by
    > yourself.


    So very true.

    - Giorgos
    Giorgos Keramidas, Jun 9, 2004
    #15
  16. Me

    CBFalconer Guest

    Re: Why do so few people know the difference between arrays andpointers.

    Michael Mair wrote:
    >
    >> What blows me out of the water is the fact that 'every' programmer
    >> comming out of college that I've interviewed thinks that pointers
    >> and arrays are the same thing.

    >
    > If it helps you feel better: We have a finite element code we are
    > working with, written in C, largely undocumented, many thousand lines,
    > and are looking for students to work for us.
    > We get many applications from so-called software engineering students
    > in their final year. Every single interview came to the point that
    > they did not "know" any programming language at all while boasting
    > knowledge of a multitude. We never ever did even get to the point
    > where such "fine details" like the differences between arrays and
    > pointers would have played a role. Same thing when we were looking
    > for someone doing some things in Matlab for us.
    > So, do not tell me about frustration ;-)
    >
    >> Man the C teachers in college aren't doing their job!

    >
    > Based on my sad experiences, I am at the moment teaching C to
    > beginners in order to get someone able to work with us.


    Maybe you are looking at the wrong end of the age spectrum?

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    CBFalconer, Jun 9, 2004
    #16
  17. Me

    Michael Mair Guest

    Re: Why do so few people know the difference between arrays andpointers.

    Hi CBFalconer,


    >>>Man the C teachers in college aren't doing their job!

    >>
    >>Based on my sad experiences, I am at the moment teaching C to
    >>beginners in order to get someone able to work with us.

    >
    > Maybe you are looking at the wrong end of the age spectrum?


    Well, that might be true - however, I have only money for
    students at my hands, and they do not come in arbitrary ages.
    When I learned C, I took to it quick enough -- of course,
    I needed another five years to get a deeper understanding
    but the basics were clear rather quickly.

    However, I am confident that about a third of my students will
    be able to work with our code after a short introduction to the
    general layout, concepts and ideas.


    Cheers,
    Michael
    Michael Mair, Jun 9, 2004
    #17
  18. Me

    Michael Mair Guest

    Hello Christian,


    > In my experience, different people learn in different ways. Some prefer
    > to actually try out things because it helps them learning. However,
    > trying out things is also useful to check if the theory is really
    > correct (I once saw a C++ programmer using the quicksort algorithm, but
    > for sorting an array of variable sized items, and the underlying methods
    > for changing an item took time O (total size of all items) when changing
    > the size of an item. The code was not O (N log N), and it was not fast
    > enough (noticable delay in the user interface in non-trivial cases)).


    True enough - especially when creating your own algorithmss you cannot
    do without :)
    (As to the complexity: Can happen. Some things you have to write down on
    a sheet of paper first in order to have the full overview of what
    happens when, how often and with what relation to N...)


    > Also, an algorithm with higher time complexity may be faster than one of
    > lower complexity up to a certain size. Consider method A taking (N^(2/3)
    > log^2 (N)) nanoseconds, and method B taking N^0.7 nanoseconds. For large
    > N, method A is faster. For any problem that can be solved in a billion
    > years, method A is slower.


    Nice example, thanks :)
    However, I was talking about linear and quadratic complexity with the
    highest leading constant for the linear algorithm being about two to
    four times higher than for the quadratic one. Here, you get a noticeable
    difference for several thousands of objects...


    Cheers,
    Michael
    Michael Mair, Jun 9, 2004
    #18
  19. Me

    JV Guest

    "Mike Wahler" <> wrote in message
    news:1kyxc.7648$...
    >


    > What's 'wrong' with using multi-dimensional arrays,
    > and what will come to me if I use one?
    >
    > I won't ask what you consider a 'fancy' declaration.
    >
    > -Mike
    >

    I think what confuses people learning C is that if you declare two arrays:

    int a[10]
    int b[10][10]

    then a[0] is integer and b[0] is a pointer to integer.
    -Jyrki
    JV, Jun 9, 2004
    #19
  20. JV <> scribbled the following:
    > "Mike Wahler" <> wrote in message
    > news:1kyxc.7648$...
    >> What's 'wrong' with using multi-dimensional arrays,
    >> and what will come to me if I use one?
    >>
    >> I won't ask what you consider a 'fancy' declaration.
    >>

    > I think what confuses people learning C is that if you declare two arrays:


    > int a[10]
    > int b[10][10]


    > then a[0] is integer and b[0] is a pointer to integer.


    It would confuse them, yes. Fortunately it's not true. b[0] is an
    array of ten integers.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "The obvious mathematical breakthrough would be development of an easy way to
    factor large prime numbers."
    - Bill Gates
    Joona I Palaste, Jun 9, 2004
    #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. jakk
    Replies:
    4
    Views:
    12,018
  2. Bill Reyn
    Replies:
    3
    Views:
    2,225
    Bob Hairgrove
    Jun 22, 2004
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,733
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    7
    Views:
    412
    Keith Thompson
    Oct 3, 2006
  5. shashi
    Replies:
    17
    Views:
    398
    Guest
    Apr 13, 2006
Loading...

Share This Page