By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
 448,824 Members | 1,627 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,824 IT Pros & Developers. It's quick & easy.

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

 P: n/a 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/ Nov 14 '05 #1
Share this Question
79 Replies

 P: n/a "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. Nov 14 '05 #2

 P: n/a 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/ Nov 14 '05 #3

 P: n/a 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? Nov 14 '05 #4

 P: n/a 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. Nov 14 '05 #5

 P: n/a 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- 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? Nov 14 '05 #6

 P: n/a "Me" wrote in message news:op**************@danocdhcp011136.americas.nok ia.com... 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 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/ Nov 14 '05 #7

 P: n/a 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. Nov 14 '05 #8

 P: n/a "Malcolm" wrote in message news:ca**********@news7.svr.pol.co.uk... "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 Nov 14 '05 #9

 P: n/a 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 Nov 14 '05 #10

 P: n/a "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) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #11

 P: n/a 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 Nov 14 '05 #12

 P: n/a "Keith Thompson" wrote in message news:ln************@nuthaus.mib.org... "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) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #13

 P: n/a In article , Michael Mair 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. Nov 14 '05 #14

 P: n/a Michael Mair 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 Nov 14 '05 #15

 P: n/a 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? Nov 14 '05 #16

 P: n/a 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 tobeginners 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 Nov 14 '05 #17

 P: n/a 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 Nov 14 '05 #18

 P: n/a "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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 Nov 14 '05 #19

 P: n/a JV scribbled the following: "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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 (pa*****@cc.helsinki.fi) ------------- 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 Nov 14 '05 #20

 P: n/a In Me writes: 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 thechapters entitled: 4: The Shocking Truth: C Arrays and Pointers Are NOT the Same! 9: More about Arrays 10: More about PointersWhat blows me out of the water is the fact that 'every' programmercomming out of college that I've interviewed thinks that pointersand arrays are the same thing.They go so far as to tell me that, in the following code, 'arr' isa pointer to an array of integers. Or they tell me that 'arr' is apointer to an 'int'. When this is not the case at all. The root of the problem is the fact that most C books don't explain "the rule" right. This is one of the few places where the text of the C standard itself is more clear than the usual tutorial book. Even K&R2 contains statements like: Since the name of an array is a synonym for the location of the initial element... that are much more misleading than helpful. After reading K&R1, I conceptualised arrays as constant pointers (or pointer constants) to an unnamed storage area, rather than the storage area itself, whose name gets automatically converted to a pointer to its first element in most contexts. This explained why you cannot assign anything to an array, but didn't scale well conceptually to arrays of arrays. It was the c.l.c FAQ that finally clarified the issue for me. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #21

 P: n/a "JV" wrote in message news:qq*******************@news1.nokia.com... "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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. No. b[0] is not a pointer. It's an array, of type 'int[10]' A pointer is not an array. An array is not a pointer. I've said this a zillion times here, I suppose I'll never be able to stop. :-) -Mike Nov 14 '05 #22

 P: n/a "Vijay Kumar R Zanvar" wrote in message news:2i************@uni-berlin.de... "Keith Thompson" wrote in message news:ln************@nuthaus.mib.org... "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. In that case, the array's name is not being used an an expression. -Mike Nov 14 '05 #23

 P: n/a "*a" <_w___k___@____p_.it> wrote in message news:Js***********************@news4.tin.it... 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 I think this remark hits the mark exactly. It seems the concise syntax and 'smalless' of C's language proper leads many to believe it's 'simple', thus they often don't see the need for deeper study, practice, and experimentation. But of course C is not really very 'simple' at all. It is indeed powerful, though. \$.02, -Mike Nov 14 '05 #24

 P: n/a "Mike Wahler" wrote 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 */ That's the difference between C usage and English usage. C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. It is correct to say that bar receives a pointer to 100 integers, and since they are in an array, it is also correct to say that it receives a pointer to an array of 100 integers. However it is also correct to say that this is false. What's 'wrong' with using multi-dimensional arrays, and what will come to me if I use one? The syntax is horrible and they have few real applications (most 2d arrays have at least one variable dimension). Your code will be hard to read and the use of multi-dimension constructs will suggest to the reader that you don't have much experience with C. Consequently when bugs appear in your code, as happens to us all from time to time, it will be re-written from scratch instead of mended. This will cause your employers to question the value of your continued employment, and in a tight market because of outsourcing to India you will not be able to find another job, and if you have few skills outside It you will be forced to take a position at Burger King where the other staff will laugh at you for being too middle class, so you will leave and hit the streets, and end your days as a tramp or beggar. Nov 14 '05 #25

 P: n/a On Wed, 9 Jun 2004, Malcolm wrote: "Mike Wahler" wrote [Malcolm himself wrote:] 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. That's the difference between C usage and English usage. C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. It is correct to say that bar receives a pointer to 100 integers, and since they are in an array, it is also correct to say that it receives a pointer to an array of 100 integers. However it is also correct to say that this is false. The simplest way out of this dilemma, in the context of the C programming language (which is always the context in this newsgroup), is to reserve the use of the word "pointer" for the C language's pointers, and to use the English term "address" for what you seem to be calling a "pointer." Thus: 'main' calls the function 'foo' with an argument which is a pointer to an 'int'. 'main' calls 'foo' with a pointer to 'int'. 'main' calls 'foo' with a pointer which holds the address of the array 'bar'. 'bar' is an array[100] of 'int'. The address of 'bar' is also the address of the first element of 'bar'. The expression 'bar' decays to a pointer to the first element of 'bar'. All pointer values have associated types. Addresses do not have types. The unary '&' operator yields a pointer to the operand object. The unary '&' operator yields the address of the operand object as a value of type "pointer to quux." All clear, no? -Arthur Nov 14 '05 #26

 P: n/a In Joona I Palaste writes: JV scribbled the following: "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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 anarray of ten integers. Which *immediately* decays into ... unless used as the operand of the sizeof or unary & operators. This is the confusing bit. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #27

 P: n/a "Malcolm" wrote in message news:ca**********@news5.svr.pol.co.uk... "Mike Wahler" wrote 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 */ That's the difference between C usage and English usage. Lacking explicit qualification to the contrary, C meanings take precedence here. C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. Actually, yes it does. The types are not the same (nor need their sizes be the same) Also, the types yielded by dereferencing those two different type pointers are not the same, nor are their sizes -- except in the case of a pointer to an array of one element -- that is, their sizes would be the same, but their types still would not). It is correct to say that bar receives a pointer to 100 integers, No it's not. The name of an array, when passed to a function, decays to a pointer to its first element. The type passed is 'pointer-to-array-element-type'. and since they are in an array, That doesn't matter. it is also correct to say that it receives a pointer to an array of 100 integers. No, it is not correct. Again: Pointer to array of 100 ints: int (*pa)[100]; Pointer to int: int *p; Those two types are *not* the same. If they were, then this would be valid: void foo(int (*arg)[100]) { } void bar(void) { int arr[100]; foo(arr); } ... but it doesn't. However it is also correct to say that this is false. Huh? What's 'wrong' with using multi-dimensional arrays, and what will come to me if I use one? The syntax is horrible A matter of opinion. I have no trouble with the syntax. and they have few real applications (most 2d arrays have at least one variable dimension). Subjective assesment. You're limiting your view to only those applications you can conceive. Your phrase 'most 2d arrays' is without context, so hasn't any useful meaning.. Your code will be hard to read Subjective opinion again. and the use of multi-dimension constructs will suggest to the reader that you don't have much experience with C. That made me laugh out loud. Consequently when bugs appear in your code, So you're saying that simply by using a 2d array has the effect of creating bugs? Oh, please. as happens to us all from time to time, Yes, being human, everyone makes mistakes occasionally (or perhaps even frequently). But the use of a particular (valid) construct is not a direct cause. What create bugs are carelessness and/or insufficient knowledge. it will be re-written from scratch instead of mended. Depending upon how 'broken' a program is, sometimes a rewrite is indeed the superior choice. This has indeed been the case a few times in my experience (both with my own code, and that of others). But the cause was never the use of a valid language construct. Sometimes I'll see that a particular construct was not the best solution, but that's a case of poor design, not 'bugs'. This will cause your employers to question the value of your continued employment, Any employer/client I might wish to work with will judge my value by that of what I produce. The value of those products is determined by a consumer market, not anyone's opinions about whether I understand C or not. and in a tight market because of outsourcing to India you will not be able to find another job, Being an unabashed capitalist, I gladly welcome competition from anyone, anywhere. I don't blame others for any problems I might have, I take responsibility for solving them. and if you have few skills outside It you will be forced to take a position at Burger King where the other staff will laugh at you for being too middle class, so you will leave and hit the streets, and end your days as a tramp or beggar. There is nothing dishonorable about working in the food service industry, or any other value-producing profession. Nor do I allow derision of others to dictate my actions. You sir, are a snob. -Mike Nov 14 '05 #28

 P: n/a Dan Pop scribbled the following: In Joona I Palaste writes:JV scribbled the following: "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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 anarray of ten integers. Which *immediately* decays into ... unless used as the operand of the sizeof or unary & operators. This is the confusing bit. Yes, I agree. It is the same situation with a one-dimensional array, so arrays of arrays don't have any magical properties. One way to understand the difference is to think of the raw bytes comprising the objects. An array is simply several values (ints in this case) put immediately after each other. Nothing more. There are no array-specific bits or bytes involved. A pointer, OTOH, is a value that constitutes the address of another value. This address value is stored in the object, but the actual values (ints in this case) it points to can be stored pretty much anywhere. A pointer definitely has extra pointer-specific bits or bytes involved - otherwise it wouldn't know where to point. Arrays can't coincide or overlap each other, any more than normal values (ints in this case) can. However, several pointers can point at the same place, or inside each other's defined pointing range. As usual, I may have been inaccurate at some points. Corrections are welcome. -- /-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\ \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/ "It's not survival of the fattest, it's survival of the fittest." - Ludvig von Drake Nov 14 '05 #29

 P: n/a Dan Pop wrote: Joona I Palaste writes:JV scribbled the following:Mike Wahler wrote: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. cat main.c #include int main(int argc, char* argv[]) { int b[10][10]; printf("%u = sizeof(b[4])\n", sizeof(b[4])); return 0; } gcc -Wall -std=c99 -pedantic -o main main.c ./main 40 = sizeof(b[4]) Which *immediately* decays into ... unless used as the operand of the sizeof or unary & operators. This is the confusing bit. I know what you mean but "decay" or "decays into" is inaccurate and confusing. It seems to imply some sort of *spontaneous* reaction which certainly does *not* occur in properly functioning C programs. The correct way to think of this is an *implicit conversion* from a reference to an array to a pointer to it's first element. Nov 14 '05 #30

 P: n/a "Mike Wahler" wrote in message C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. Actually, yes it does. The types are not the same (nor need their sizes be the same) Also, the types yielded by dereferencing those two different type pointers are not the same, nor are their sizes -- except in the case of a pointer to an array of one element -- that is, their sizes would be the same, but their types still would not). Say we want to write a function to return a cursor position. Any C programmer would write this void getcursorxy(int *x, int *y) { *x = xposition; *y = yposition; } Now imagine a function to calculate a correlation coefficient. Again any C programmer would write double correlation(int *xvals, int *yvals, int N) Pointer to array of 100 ints: int (*pa)[100]; Pointer to int: int *p; Those two types are *not* the same. No, but int *p is not constrained to pointing at a memory object containing only one integer. Nov 14 '05 #31

 P: n/a On Wed, 9 Jun 2004 22:00:11 +0100, "Malcolm" wrote: "Mike Wahler" wrote in message > C doesn't distinguish between a pointer to an area of memory > containing a single integer, or an area containing an array of > integers. Actually, yes it does. The types are not the same (nor need their sizes be the same) Also, the types yielded by dereferencing those two different type pointers are not the same, nor are their sizes -- except in the case of a pointer to an array of one element -- that is, their sizes would be the same, but their types still would not).Say we want to write a function to return a cursor position. Any Cprogrammer would write thisvoid getcursorxy(int *x, int *y){ *x = xposition; *y = yposition;}Now imagine a function to calculate a correlation coefficient. Again any Cprogrammer would writedouble correlation(int *xvals, int *yvals, int N) Pointer to array of 100 ints: int (*pa)[100]; Pointer to int: int *p; Those two types are *not* the same.No, but int *p is not constrained to pointing at a memory object containingonly one integer. int *p, when properly initialized, points to a single int by definition. The fact that p+1 may also be the address of an int is a function of the program design and not an inherent property of p. <> Nov 14 '05 #32

 P: n/a "Malcolm" wrote: "Mike Wahler" wrote in message C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. Actually, yes it does. The types are not the same (nor need their sizes be the same) Also, the types yielded by dereferencing those two different type pointers are not the same, nor are their sizes -- except in the case of a pointer to an array of one element -- that is, their sizes would be the same, but their types still would not). Say we want to write a function to return a cursor position. Any C programmer would write this void getcursorxy(int *x, int *y) { *x = xposition; *y = yposition; } Erm... I'd almost certainly not write it like that. Even if the global values would be unavoidable (and I would try to avoid them), I'd be more likely to write struct coords getcursorxy() { struct coords t; t.x=global_x; t.y=global_y; return t; } Now imagine a function to calculate a correlation coefficient. Again any C programmer would write double correlation(int *xvals, int *yvals, int N) Yes, in this case I probably would. I fail to see the problem, btw. I see your point (that any given int pointer can point at memory the size of one int, two ints, or a gazillion ints); but I do not see why this is a problem to you. For any given function, a pointer can point at - one object (possibly part of a larger memory area) - in this case, you use *ptr, and the rest of the memory, if any, is irrelevant; - a number of objects, which can be as low as one and as high as the sky, or possibly even zero - in which case, you need to pass in the number of elements in any case, no matter whether there happens to be just one object in this single call or not. Someone who does not understand this will have problems programming in C, yes. So what? Let him "program" in HTML; should suit him fine. Pointer to array of 100 ints: int (*pa)[100]; Pointer to int: int *p; Those two types are *not* the same. No, but int *p is not constrained to pointing at a memory object containing only one integer. Again: so what? If you expect one int, other ints which happen to be positioned next to your int in memory are irrelevant. If I send a letter to you, should I care whether you live in a detached house or in a flat? Of course not - as long as I have your correct address, the letter will arrive fine. Richard Nov 14 '05 #33

 P: n/a "Joona I Palaste" wrote in message news:ca**********@oravannahka.helsinki.fi... JV scribbled the following: "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net... 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 (pa*****@cc.helsinki.fi) ------------- 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 Hmm, it seems that I still have to work on how to present my ideas clearly:). So lets say that you can use notation b[0] as a pointer to integer and you can assign a[0] to integer variable. So you can't tell if you see expression like a[b] what it actually is without knowing the declaration. And I KNOW that arrays are not pointers and still I managed to get it wrong in my previous post ... -Jyrki Nov 14 '05 #34

 P: n/a JV wrote: "Joona I Palaste" wrote in message JV scribbled the following: "Mike Wahler" wrote in message 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. Hmm, it seems that I still have to work on how to present my ideas clearly:). So lets say that you can use notation b[0] as a pointer to integer and you can assign a[0] to integer variable. So you can't tell if you see expression like a[b] what it actually is without knowing the declaration. And I KNOW that arrays are not pointers and still I managed to get it wrong in my previous post ... You also need to work on your snipping technique and delineation of your sig (with "-- "). This has minimal snippage, but compare it to your actual article. -- Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! Nov 14 '05 #35

 P: n/a "Malcolm" wrote in message news:ca**********@news5.svr.pol.co.uk... "Mike Wahler" wrote in message C doesn't distinguish between a pointer to an area of memory containing a single integer, or an area containing an array of integers. Actually, yes it does. The types are not the same (nor need their sizes be the same) Also, the types yielded by dereferencing those two different type pointers are not the same, nor are their sizes -- except in the case of a pointer to an array of one element -- that is, their sizes would be the same, but their types still would not). Say we want to write a function to return a cursor position. Any C programmer would write this void getcursorxy(int *x, int *y) { *x = xposition; *y = yposition; } Now imagine a function to calculate a correlation coefficient. Again any C programmer would write double correlation(int *xvals, int *yvals, int N) Pointer to array of 100 ints: int (*pa)[100]; Pointer to int: int *p; Those two types are *not* the same. No, but int *p is not constrained to pointing at a memory object containing only one integer. Thank you for participating in this interview. We have your resume on file. Don't call us, we'll call you. -Mike Nov 14 '05 #36

 P: n/a "Joona I Palaste" wrote in message news:ca**********@oravannahka.helsinki.fi... Dan Pop scribbled the following: In Joona I Palaste writes:JV scribbled the following: "Mike Wahler" wrote in message news:1k*****************@newsread2.news.pas.earthl ink.net...> 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 anarray of ten integers. Which *immediately* decays into ... unless used as the operand of the sizeof or unary & operators. This is the confusing bit. Yes, I agree. It is the same situation with a one-dimensional array, so arrays of arrays don't have any magical properties. One way to understand the difference is to think of the raw bytes comprising the objects. An array is simply several values (ints in this case) put immediately after each other. Nothing more. There are no array-specific bits or bytes involved. A pointer, OTOH, is a value that constitutes the address of another value. This address value is stored in the object, but the actual values (ints in this case) it points to can be stored pretty much anywhere. A pointer definitely has extra pointer-specific bits or bytes involved - otherwise it wouldn't know where to point. Arrays can't coincide or overlap each other, any more than normal values (ints in this case) can. However, several pointers can point at the same place, or inside each other's defined pointing range. As usual, I may have been inaccurate at some points. Corrections are welcome. The only thing above I (mildly) object to is this part: A pointer, OTOH, is a value that constitutes the address of another value. This address value is stored in the object, but the actual values ... I'd change that to: A pointer, OTOH, is an object that can represent the address of another object. This address value is stored in the pointer object, but the actual objects ... IOW objects represent values, but not all values are objects. -Mike Nov 14 '05 #37

 P: n/a "JV" wrote in message news:pW*******************@news1.nokia.com... So you can't tell if you see expression like a[b] what it actually is without knowing the declaration. Correct, and this is the case with any statement referring to an object, array or not. i = j; /* we need to see declarations of 'i' and 'j' to know what they are */ And I KNOW that arrays are not pointers and still I managed to get it wrong in my previous post ... Yes, slee can be a sippery slubject. :-) -Mike Nov 14 '05 #38

 P: n/a Me wrote: Man the C teachers in college aren't doing their job! At the university I recently graduated from, the professors didn't "teach" languages. They used languages to show various CS concepts. Primarily, it was done in C++, although the networking and OS classes used C. I think this is rather typical. Also, there seems to be a shift towards software engineering and away from general computer science. Dunno if this is good or not. As a recent graduate (this last week), I just started a new job, and I've found out that I'm pretty rusty on pointers, bit-shifting/byte-packing techniques, big/little-endians, etc. However, I feel that I'm pretty good at software design, object-oriented programming, project management, etc. Nov 14 '05 #39

 P: n/a "Richard Bos" wrote in message If I send a letter to you, should I care whether you live in a detached house or in a flat? Of course not - as long as I have your correct address, the letter will arrive fine. But you need to know whether you are sending one gas bill (to the detached house) or many (to each resident of the block of flats). If "int *ptr;" were a pointer to an integer, period, then ptr[100] = x would be illegal. Nov 14 '05 #40

 P: n/a Mike Wahler wrote: IOW objects represent values, but not all values are objects. Can you give us an example of a value that is *not* an object? Nov 14 '05 #41

 P: n/a On Thu, 10 Jun 2004, E. Robert Tisdale wrote: Mike Wahler wrote: IOW objects represent values, but not all values are objects. Can you give us an example of a value that is *not* an object? (int)42. -Arthur, signing off Nov 14 '05 #42

 P: n/a E. Robert Tisdale wrote: Can you give us an example of a value that is *not* an object? 1. (With or without the decimal point.) -- ++acr@,ka" Nov 14 '05 #43

 P: n/a "Malcolm" wrote:"Richard Bos" wrote in message If I send a letter to you, should I care whether you live in a detached house or in a flat? Of course not - as long as I have your correct address, the letter will arrive fine.But you need to know whether you are sending one gas bill (to the detachedhouse) or many (to each resident of the block of flats).If "int *ptr;" were a pointer to an integer, period, thenptr[100] = xwould be illegal. Since ptr[100] is just shorthand for (*((ptr)+(100))) , why should it be illegal? Array subscripting is plain old pointer arithmetic wrapped up in a nice syntactic construct, and it doesn't matter at all, if it's performed on a 'genuine' pointer or on one yielded by 'array decay'. In your example ptr *is* a pointer to an integer - no more, no less. Period. Regards -- Irrwahn Grausewitz (ir*******@freenet.de) welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt clc faq-list : http://www.faqs.org/faqs/C-faq/faq/ clc OT guide : http://benpfaff.org/writings/clc/off-topic.html Nov 14 '05 #44

 P: n/a "E. Robert Tisdale" wrote in message news:ca**********@nntp1.jpl.nasa.gov... Mike Wahler wrote: IOW objects represent values, but not all values are objects. Can you give us an example of a value that is *not* an object? Any numeric literal. -Mike Nov 14 '05 #45

 P: n/a "Malcolm" wrote in message news:ca**********@newsg1.svr.pol.co.uk... "Richard Bos" wrote in message If I send a letter to you, should I care whether you live in a detached house or in a flat? Of course not - as long as I have your correct address, the letter will arrive fine. But you need to know whether you are sending one gas bill (to the detached house) or many (to each resident of the block of flats). That's why we must use 'element count' arguments to functions which use pointer (to element-type) arguments to process arrays. Start at first flat, deliver bill, move to next flat, deliver bill. -Mike Nov 14 '05 #46

 P: n/a Arthur J. O'Dwyer wrote: On Thu, 10 Jun 2004, E. Robert Tisdale wrote:Mike Wahler wrote:IOW objects represent values, but not all values are objects.Can you give us an example of a value that is *not* an object? (int)42. Wrong. That's an object of type int with the [constant] value of 42. Nov 14 '05 #47

 P: n/a Joe Laughlin wrote: Also, there seems to be a shift towards software engineering and away from general computer science. You're going need to define those two terms for meaningful conversation. Brian Rodenborn Nov 14 '05 #48

 P: n/a E. Robert Tisdale wrote: Mike Wahler wrote: IOW objects represent values, but not all values are objects. Can you give us an example of a value that is *not* an object? int a = 12; The identifier 'a' is an object of type int, with the value of 12. The integer literal 12 has the value of 12 but is not an object. -- Alex Monjushko (mo*******@hotmail.com) Nov 14 '05 #49

 P: n/a Default User wrote: Joe Laughlin wrote: Also, there seems to be a shift towards software engineering and away from general computer science. You're going need to define those two terms for meaningful conversation. Brian Rodenborn "general computer science" => theory, algorithms, lower-level stuff "software engineering" => the process of developing a complex software system That's how I understand them anyways. Nov 14 '05 #50

79 Replies

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more C / C++ Questions on Bytes