Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beej’s Guide to C Programming [pdf]

beej.us

Post reply on HN
Print view View original

21–30 of 178 posts

Re: Beej’s Guide to C Programming [pdf]

#21

Post by cassepipe »

blunte wrote: post #6

IMO, pointers are less difficult to comprehend than other abstractions, like lambdas are. If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory. Anyway, many more ana…

Pointers aren't that complicated but C syntax is misleading imho until someone comes along and tells you that the declaration syntax "follows use", which does not seem like the greatest idea. Then you get used to it and forget about it but when you don't know the principle behind declaration syntax, it does not help you reason about the language.

Re: Beej’s Guide to C Programming [pdf]

#22

Post by young_unixer »

cassepipe wrote: post #21
blunte wrote: post #6

IMO, pointers are less difficult to comprehend than other abstractions, like lambdas are. If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory. Anyway, many more ana…

Pointers aren't that complicated but C syntax is misleading imho until someone comes along and tells you that the declaration syntax "follows use", which does not seem like the greatest idea. Then you get used to it and forget about it but when you don't know the principle behind declaration syntax, it does not help you reason about the language.

Yup. I spent a ton of time trying to make sense of pointer syntax (* operator/modifier), until I realized that it didn't really make sense (except for the simplest cases) and then I could get on my life.

Re: Beej’s Guide to C Programming [pdf]

#23

Post by shric »

bluetomcat wrote: post #14
aphrax wrote: post #7

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for me... Edit: poor grammar

Just another integral data type which supports not only arithmetic (adding or removing an integral value), but also "dereferencing" which means getting a value of the pointed-to type at the pointed-to address. The quantities added or removed in arithmetic operations are the same as the size of the type that is being pointed to.

It's incorrect to call a pointer an integral type. It doesn't behave like an integer (you can't add two pointers together). You can't even subtract two pointers from each other unless they point into the same array (or one element past) without causing undefined behaviour. You can't even reliably convert a pointer generally to an integer and back again unless it's a void *.

Edit: just remembered I wrote a rambling on this in 2014: https://ramblings.implicit.net/c/2014/04/21/pointers-are-not...

Re: Beej’s Guide to C Programming [pdf]

#24

Post by caseyavila »

andi999 wrote: post #20
caseyavila wrote: post #17

> It’s especially insidious because once you grok pointers, they’re suddenly easy. But up until that moment, they’re slippery eels. I'm sort of a C beginner myself. I understand pointers, and I do remember they clicked in my mind suddenly. The moment before, I didn't understand at all. I also love the quirkiness of this guide. Definitely going to give this a read.

Do you mean the general concept or like: a is a pointer to an array of functions which return pointers to functions which return ints and take double arrays as parameters. This somehow never really clicked (or actually it clicked and declicked somehow)

For me it was the practical understanding. I understood the concept of a pointer, but I wasn't confident in writing code that used that used them or (more importantly) reading code. I would see an asterisk, multiple asterisks, or ampersands, and would get confused with the code. I do think some of the issues I encountered had to do with the notation of pointers. The asterisk serving as a symbol to both declare a pointer variable and dereference one.

Re: Beej’s Guide to C Programming [pdf]

#25

Post by DyslexicAtheist »

aphrax wrote: post #7

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for me... Edit: poor grammar

around 25 years ago I got so frustrated because I hit the same brick walls over and over especially with advanced pointer stuff. It sounds silly today but what helped me are some really basic books about C. iirc the "for dummies" series and others.

It took another couple of years until I understood what I lacked wasn't time spent reading another section on pointers but additional tooling. Using a debugger and stepping through programs was the next breakthrough.

Looking back today understanding my C (on UNIX) isn't just the language it's a whole ecosystem of tools to measure what is going on and manipulating state so that I can troubleshoot. After gdb came valgrind, strace, lsof, signal handling (kill), process control, gcov, the appropriate type of CFLAGS to use (e.g. the compiler itself) and how to stay sane using Make.

None of them have to do with pointers but they make life a lot easier. To become productive at this takes years but becoming good took me decades. C (imho) isn't just another language but a complete career path with dozens of branches into other areas.

If you stay patient with yourself and treat it as a journey instead of a milestone it can deepen your understanding of systems (nod to eBPF) in situations many others will bail out long before.

Don't give up and then not much will look scary any more.

Re: Beej’s Guide to C Programming [pdf]

#26

Post by bluetomcat »

qsort wrote: post #16
blunte wrote: post #6

IMO, pointers are less difficult to comprehend than other abstractions, like lambdas are. If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory. Anyway, many more ana…

What's difficult to understand about pointers isn't the concept of a pointer itself, or even * and &, it's the fact that working with pointers requires you to simultaneously understand different abstraction levels. While it's not unique to pointers, and it's in fact the case for most nontrivial programming tasks, what's unique about C is that pointers are so pervasive you can't really do anything if you don't underst…

In C, pointers require you to think deeply about the ownership and lifetime of any "allocated object" at runtime. How long does it live, who is responsible for the deallocation, how many pointers does your program hold to that object (dangling issues). Ultimately, it can lead to a cleaner design if these issues are taken seriously up-front.

Re: Beej’s Guide to C Programming [pdf]

#28

Post by unwind »

qsort wrote: post #16
blunte wrote: post #6

IMO, pointers are less difficult to comprehend than other abstractions, like lambdas are. If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory. Anyway, many more ana…

What's difficult to understand about pointers isn't the concept of a pointer itself, or even * and &, it's the fact that working with pointers requires you to simultaneously understand different abstraction levels. While it's not unique to pointers, and it's in fact the case for most nontrivial programming tasks, what's unique about C is that pointers are so pervasive you can't really do anything if you don't underst…

These are good points. I can sometimes feel that Python is more pointer-y (?) than people expect, with stuff like:

    a = {"one": 1, "two": 2 }
    b = a
    b["two"] = 99
    print(a["two"])
The above prints 99, since "b = a" does not copy the value (the dictionary) but just the reference to the value ("the pointer", kind of). This is surprising to some people.

Re: Beej’s Guide to C Programming [pdf]

#29

Post by aphrax »

unwind wrote: post #9
aphrax wrote: post #7

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for me... Edit: poor grammar

That is fascinating, thanks for sharing. What part of pointers is it that makes it so hard for you to grasp, if you have any thoughts? Do you have any experience in other programming languages? How familiar are you with low-level computer architecture, at the CPU/memory level? I guess one important part is to realize that in C, variables are basically names for memory locations, that in turn hold values. In other lan…

Thanks for this - I think you are on to something when you mention the low level architecture, on reflection this is where I need to fully understand the concepts - I'm messing around in this area with the usual (Nand to Tetris) type info/tutorials. I'll then come back to this manual I'm sure. Like I say - I've enjoyed it quite a bit. Its certainly me lacking - not the book!

Re: Beej’s Guide to C Programming [pdf]

#30

Post by qsort »

bluetomcat wrote: post #26
qsort wrote: post #16

Earlier quoted context omitted.

What's difficult to understand about pointers isn't the concept of a pointer itself, or even * and &, it's the fact that working with pointers requires you to simultaneously understand different abstraction levels. While it's not unique to pointers, and it's in fact the case for most nontrivial programming tasks, what's unique about C is that pointers are so pervasive you can't really do anything if you don't underst…

In C, pointers require you to think deeply about the ownership and lifetime of any "allocated object" at runtime. How long does it live, who is responsible for the deallocation, how many pointers does your program hold to that object (dangling issues). Ultimately, it can lead to a cleaner design if these issues are taken seriously up-front.

I don't disagree with that, but most cases fall within a pretty clear pattern:

- typedef struct { ... } foo

- foo *foo_create()

- void foo_destroy(foo *)

- a bunch of functions that take foo* as their first arg

which is kind of the same as a class and only more error-prone.

I say this as someone who actually _likes_ C, but the manual memory management model is very often unnecessary, confusing, repetitive. There was an idea some time ago of a language extension that would extend the concept of automatic storage duration to allow an explicit destructor to be called when the variable goes out of scope, like variables in some languages. I genuinely think things like that would make the language a bit more ergonomic without fundamentally changing its nature.

Post reply on HN