10 ms·

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

alderssc 15y ago
I would hazard to guess its due to two things: 1) a lack of understanding about how the machine works, and in particular the way the memory is organized; and 2) lack of explanation of why anyone would need to use pointers. Introducing pointers in the context of a linked list, or explaining call-by-reference would probably help make things more concrete.
- younata 15y ago
  I have friends who had to take an intro to C++ as their first (and only) programming class. I heard them talking about passing arguments to functions as "call by reference" many times, and it was obvious they had no idea what they were talking about, just regurgitating what the instructor said.
daxelrod 15y ago
For me, the indirection of pointers was one of the fundamental CS concepts that required real effort to understand. Before that point, I had never clearly separated the concept of a variable and its value. It took a huge conceptual leap to think about a variable that didn't hold a value, but rather, the location of a value. It took some serious mental gymnastics to deal with pointers n-levels deep. Mind you, this was actually Perl references, not pointers, so I didn't even have to try to comprehend doing math on them. After a while, of course, it became second nature. My favorite aspect of CS is that every so often, I run into a wall of conceptual understanding that requires completely changing how I think in order to move forward. Have you never had moments like this, or were they just different topics?
- ramidarigaz 15y ago
  Actually learning about the stack was one of my big 'aha!' moments. I sorta' knew it existed, but I didn't really comprehend it.
gregjor 15y ago
K&R chapter 5.5, Character Pointers and Functions, explains pointers and shows how they are used in C. It's probably the clearest explanation of pointers ever written, and it doesn't require any understanding of hardware or assembly language (though that would help). I remember reading those three pages over and over and experimenting with the code until I got it. I probably spent several days studying the pointer chapter back when I was a teenager. The light bulb eventually went on and C pointers made sense -- until learning C my programming experience was mainly with time-shared BASIC. The stepwise refinement of an indexed array version of strcpy() to a pointer-based version is a masterpiece of programming writing -- I still refer programmers I am mentoring to that chapter. Finishing the strcpy() example with the one-liner while (*s++ = *t++) ; the authors write "Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs." I've found that programmers either get that line of code or they don't, and those who don't haven't mastered their craft.
- eropple 15y ago
  Getting it or not is one thing, but I'd advocate keelhauling anyone who wrote that sort of thing in production. The "notational convenience" is more obnoxious than anything. But, then, I'm not particularly a fan of terseness for the sake of being terse.
  - gregjor 15y ago
    I'm not a fan of wordiness for the sake of being wordy. If you think the code is terse just to show off you are missing the point. There's a difference between writing obscure code and writing concise idiomatic code -- see "The Elements of Programming Style" by Kernighan and Plauger. I'd rather Kernighan, Ritchie, Thompson, Pike, et al. write my production code than someone who thinks C pointer idioms are a punishable offense. "That sort of thing" has been in production in the C libraries, the UNIX kernel, and all of the brilliant utilities that make up UNIX for over 30 years. It's also very much in production code at Google. You might want to read Paul Graham's thoughts on succinct code at http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html and Rob Pike's "Notes On Programming in C" at http://doc.cat-v.org/bell_labs/pikestyle http://doc.cat-v.org/bell_labs/pikestyle.
deleted 15y ago
[deleted]
cturner 15y ago
I never really understood why they didn't grasp pointers The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time. #include <stdio.h> void eg(int i) { int *j = &i; // "huh? Put the address of i into *j?" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } With more detail. In the line.. int *var = something; .. the system assigns to the pointer. Yet in.. *var = 6; .. it assigns to the contents of the pointer. Common usage creates further room for confusion: int *var; // <- this is what people write int* var; // <- instead of this If they'd made the syntax ".int var", and then used * solely for dereferencing, people wouldn't have these problems learning pointers. Consider #include <stdio.h> void eg(int i) { .int j = &i; *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } Further confusion comes from (1) special arrangements around string declaration and (2) printf use of %s to expect a string pointer when %d and %f expects (non-pointer) simple int and simple float. char* something = "huh? so now this does goe into *something?";
- endgame 15y ago
  If you remember that the experiment here was to make declaration follow use, it makes sense. I consider it a failed experiment, but it does make sense.
- deleted 15y ago
  [deleted]
- atakan_gurkan 15y ago
  To avoid this sort of thing, I use: #include <stdio.h> void eg(int i) { int *j; // "j is a pointer and (hence) *j is an int" j = &i; // "Put the address of i into *j? Yup" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } Perhaps this is because I am just used to it, but I really see very little room for confusion here. The common usage avoids confusion, if you do not insist on assignment at the time of declaration. To address your second confusion, just keep in mind that strings are char arrays and an array's name is actually a pointer. Again, I find this very straightforward.
Goladus 15y ago
I can't speak for your friends, but while I had zero problems with pointers conceptually, I still had trouble using them in C. The problem wasn't the simple case of declaring a pointer and taking its reference, the difficulty came when the programs got complex and required agreement between function declarations, actual parameters in calls, and use within the functions.
adestefan 15y ago
Mainly because variable declarations are "backwards" in C. People try to read code left to right, but C declarations should be read right to left. Pile one things like the dual use of the static keyword, typedefs, and having multiple consts in a declaration figuring out the type of a variable can be a real chore. Dan Saks has a great article that hits on just the issues with const. http://dansaks.com/articles/1998-06%20Placing%20const%20in%20Declarations.pdf http://dansaks.com/articles/1998-06%20Placing%20const%20in%2...
- sp332 15y ago
  Or the classic "clockwise spiral rule" http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html :)

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

alderssc 15y ago

I would hazard to guess its due to two things: 1) a lack of understanding about how the machine works, and in particular the way the memory is organized; and 2) lack of explanation of why anyone would need to use pointers. Introducing pointers in the context of a linked list, or explaining call-by-reference would probably help make things more concrete.

younata 15y ago
I have friends who had to take an intro to C++ as their first (and only) programming class. I heard them talking about passing arguments to functions as "call by reference" many times, and it was obvious they had no idea what they were talking about, just regurgitating what the instructor said.

daxelrod 15y ago

For me, the indirection of pointers was one of the fundamental CS concepts that required real effort to understand. Before that point, I had never clearly separated the concept of a variable and its value. It took a huge conceptual leap to think about a variable that didn't hold a value, but rather, the location of a value. It took some serious mental gymnastics to deal with pointers n-levels deep. Mind you, this was actually Perl references, not pointers, so I didn't even have to try to comprehend doing math on them. After a while, of course, it became second nature. My favorite aspect of CS is that every so often, I run into a wall of conceptual understanding that requires completely changing how I think in order to move forward. Have you never had moments like this, or were they just different topics?

ramidarigaz 15y ago
Actually learning about the stack was one of my big 'aha!' moments. I sorta' knew it existed, but I didn't really comprehend it.

gregjor 15y ago

K&R chapter 5.5, Character Pointers and Functions, explains pointers and shows how they are used in C. It's probably the clearest explanation of pointers ever written, and it doesn't require any understanding of hardware or assembly language (though that would help). I remember reading those three pages over and over and experimenting with the code until I got it. I probably spent several days studying the pointer chapter back when I was a teenager. The light bulb eventually went on and C pointers made sense -- until learning C my programming experience was mainly with time-shared BASIC. The stepwise refinement of an indexed array version of strcpy() to a pointer-based version is a masterpiece of programming writing -- I still refer programmers I am mentoring to that chapter. Finishing the strcpy() example with the one-liner while (*s++ = *t++) ; the authors write "Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs." I've found that programmers either get that line of code or they don't, and those who don't haven't mastered their craft.

eropple 15y ago
Getting it or not is one thing, but I'd advocate keelhauling anyone who wrote that sort of thing in production. The "notational convenience" is more obnoxious than anything. But, then, I'm not particularly a fan of terseness for the sake of being terse.
- gregjor 15y ago
  I'm not a fan of wordiness for the sake of being wordy. If you think the code is terse just to show off you are missing the point. There's a difference between writing obscure code and writing concise idiomatic code -- see "The Elements of Programming Style" by Kernighan and Plauger. I'd rather Kernighan, Ritchie, Thompson, Pike, et al. write my production code than someone who thinks C pointer idioms are a punishable offense. "That sort of thing" has been in production in the C libraries, the UNIX kernel, and all of the brilliant utilities that make up UNIX for over 30 years. It's also very much in production code at Google. You might want to read Paul Graham's thoughts on succinct code at http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html and Rob Pike's "Notes On Programming in C" at http://doc.cat-v.org/bell_labs/pikestyle http://doc.cat-v.org/bell_labs/pikestyle.

deleted 15y ago

[deleted]

cturner 15y ago

I never really understood why they didn't grasp pointers The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time. #include <stdio.h> void eg(int i) { int *j = &i; // "huh? Put the address of i into *j?" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } With more detail. In the line.. int *var = something; .. the system assigns to the pointer. Yet in.. *var = 6; .. it assigns to the contents of the pointer. Common usage creates further room for confusion: int *var; // <- this is what people write int* var; // <- instead of this If they'd made the syntax ".int var", and then used * solely for dereferencing, people wouldn't have these problems learning pointers. Consider #include <stdio.h> void eg(int i) { .int j = &i; *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } Further confusion comes from (1) special arrangements around string declaration and (2) printf use of %s to expect a string pointer when %d and %f expects (non-pointer) simple int and simple float. char* something = "huh? so now this does goe into *something?";

endgame 15y ago
If you remember that the experiment here was to make declaration follow use, it makes sense. I consider it a failed experiment, but it does make sense.
deleted 15y ago
[deleted]
atakan_gurkan 15y ago
To avoid this sort of thing, I use: #include <stdio.h> void eg(int i) { int *j; // "j is a pointer and (hence) *j is an int" j = &i; // "Put the address of i into *j? Yup" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } Perhaps this is because I am just used to it, but I really see very little room for confusion here. The common usage avoids confusion, if you do not insist on assignment at the time of declaration. To address your second confusion, just keep in mind that strings are char arrays and an array's name is actually a pointer. Again, I find this very straightforward.

Goladus 15y ago

I can't speak for your friends, but while I had zero problems with pointers conceptually, I still had trouble using them in C. The problem wasn't the simple case of declaring a pointer and taking its reference, the difficulty came when the programs got complex and required agreement between function declarations, actual parameters in calls, and use within the functions.

adestefan 15y ago

Mainly because variable declarations are "backwards" in C. People try to read code left to right, but C declarations should be read right to left. Pile one things like the dual use of the static keyword, typedefs, and having multiple consts in a declaration figuring out the type of a variable can be a real chore. Dan Saks has a great article that hits on just the issues with const. http://dansaks.com/articles/1998-06%20Placing%20const%20in%20Declarations.pdf http://dansaks.com/articles/1998-06%20Placing%20const%20in%2...

sp332 15y ago
Or the classic "clockwise spiral rule" http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html :)