4 ms·

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 w

by 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.
  - eropple 15y ago
    I've read both of those links in the past, thanks. And while, yes, "idiomatic" (read: terse and annoying) code is in use in all those areas, I don't have to see it. Code should be pleasant to read wherever possible. That simply is not, to my mind, pleasant to read. It's one step away from Perl line noise (which I avoid, too). You may disagree with this, and that's fine--different strokes for different folks. I have no interest in seeing it in code I have to maintain; you might, and that's OK by me. (To be fair, however, I have little interest in working with or, god forbid, maintaining C or C++ code under any circumstances. They press the buttons of a group of developers to which I don't belong.)
- nitrogen 15y ago
  I imagine terseness was a lot more valuable when everyone was programming on an 80x25 (or smaller) terminal or even punch cards. I've seen a few examples of code like this from early libc implementations of functions like strcpy, malloc, etc. Take a look at the source code of BSD libc -- some of that stuff is historic. I myself never got much into the terseness game, since apart from a brief stint using gwbasic and later QuickBasic at 80x25, I learned programming using DJGPP in DOS with the RHIDE IDE. The IDE could trick the VGA into displaying something like 132x60, leaving plenty of room for descriptive code.
  - justincormack 15y ago
    This type of code used to run faster when compilers did less. It makes no difference now. I think that is why it has stuck around. I prefer to write C that uses array references where it makes things clearer.
    - gregjor 15y ago
      Don't think so. Kernighan et al. are the first to say code should be clear first and made fast only if it matters. This is clear code. It may (or may not) be faster than an array-based version but that's not the point of the exercise in K&R -- the point is to teach how pointers work.
    - nitrogen 15y ago
      You'd be surprised what the compiler still doesn't do. For example, when writing a toy high-performance memory allocator for a university class, I was able to gain a significant[1] performance boost by replacing __attribute__((packed)) structs with pointer arithmetic #defines for the allocation block descriptors, with an identical memory layout. [1] I don't remember the exact gain, but it was at least 10%.
  - gregjor 15y ago
    The Go language tutorial and examples look right at home alongside K&R. Likewise jQuery and other Javascript libraries, where terseness is valued due to bandwidth rather than screen size. The idiomatic C style is so natural to me now I don't see it as a defect to fix or a game I'm playing. It's how I learned to program in C because I learned from K&R, and if they aren't the authorities I don't know who is. When I see wordy and bloated Java-style code it reminds me of the years I spent writing COBOL. Ultimately, though, it's not efficiency or a desire to show off or confuse other programmers that influences my style. To me code that does what it needs to with no extra fluff is beautiful. When I see while (*s++ = *t++) ; I know what it does -- I don't need any comments or "descriptive" variable name or an explicit test for a null byte to make it clearer. If a programmer comes across a line of code that he or she doesn't understand the fault may be with the author, but it may be with the reader. In my experience there are a lot of unskilled programmers who quickly decide that any code they look at is badly written and should be thrown out. I don't think I should dumb down my code just so programmers less fluent with C can understand it. I have to consult a dictionary sometimes when I read Cormac McCarthy or Nabokov but I don't think they should write with easier words for my sake.
- deleted 15y ago
  [deleted]

by gregjor 15y ago

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.
- eropple 15y ago
  I've read both of those links in the past, thanks. And while, yes, "idiomatic" (read: terse and annoying) code is in use in all those areas, I don't have to see it. Code should be pleasant to read wherever possible. That simply is not, to my mind, pleasant to read. It's one step away from Perl line noise (which I avoid, too). You may disagree with this, and that's fine--different strokes for different folks. I have no interest in seeing it in code I have to maintain; you might, and that's OK by me. (To be fair, however, I have little interest in working with or, god forbid, maintaining C or C++ code under any circumstances. They press the buttons of a group of developers to which I don't belong.)
nitrogen 15y ago
I imagine terseness was a lot more valuable when everyone was programming on an 80x25 (or smaller) terminal or even punch cards. I've seen a few examples of code like this from early libc implementations of functions like strcpy, malloc, etc. Take a look at the source code of BSD libc -- some of that stuff is historic. I myself never got much into the terseness game, since apart from a brief stint using gwbasic and later QuickBasic at 80x25, I learned programming using DJGPP in DOS with the RHIDE IDE. The IDE could trick the VGA into displaying something like 132x60, leaving plenty of room for descriptive code.
- justincormack 15y ago
  This type of code used to run faster when compilers did less. It makes no difference now. I think that is why it has stuck around. I prefer to write C that uses array references where it makes things clearer.
  - gregjor 15y ago
    Don't think so. Kernighan et al. are the first to say code should be clear first and made fast only if it matters. This is clear code. It may (or may not) be faster than an array-based version but that's not the point of the exercise in K&R -- the point is to teach how pointers work.
  - nitrogen 15y ago
    You'd be surprised what the compiler still doesn't do. For example, when writing a toy high-performance memory allocator for a university class, I was able to gain a significant[1] performance boost by replacing __attribute__((packed)) structs with pointer arithmetic #defines for the allocation block descriptors, with an identical memory layout. [1] I don't remember the exact gain, but it was at least 10%.
- gregjor 15y ago
  The Go language tutorial and examples look right at home alongside K&R. Likewise jQuery and other Javascript libraries, where terseness is valued due to bandwidth rather than screen size. The idiomatic C style is so natural to me now I don't see it as a defect to fix or a game I'm playing. It's how I learned to program in C because I learned from K&R, and if they aren't the authorities I don't know who is. When I see wordy and bloated Java-style code it reminds me of the years I spent writing COBOL. Ultimately, though, it's not efficiency or a desire to show off or confuse other programmers that influences my style. To me code that does what it needs to with no extra fluff is beautiful. When I see while (*s++ = *t++) ; I know what it does -- I don't need any comments or "descriptive" variable name or an explicit test for a null byte to make it clearer. If a programmer comes across a line of code that he or she doesn't understand the fault may be with the author, but it may be with the reader. In my experience there are a lot of unskilled programmers who quickly decide that any code they look at is badly written and should be thrown out. I don't think I should dumb down my code just so programmers less fluent with C can understand it. I have to consult a dictionary sometimes when I read Cormac McCarthy or Nabokov but I don't think they should write with easier words for my sake.
deleted 15y ago
[deleted]