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

41–50 of 178 posts

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

#41

Post by jhgb »

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.

> In C, pointers require you to think deeply about the ownership and lifetime of any "allocated object" at runtime.

Unless you decide you use libgc, presumably?

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

#42

Post by serial_dev »

unwind wrote: post #28
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…

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.

It's also similar in Java's pass-by-value vs pass-by-reference (pass as well as copy), if I recall correctly.

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

#43

Post by argvargc »

aphrax wrote: post #29
unwind wrote: post #9

Earlier quoted context omitted.

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!

Something that might help is understanding a very fundamental thing about computers: they are very, very stupid.

Essentially, they don't/can't know anything about anything, at the most fundamental levels of their construction, and have to be hand-held every tiny step of the way.

A computer is essentially a highly complex arrangement of on/off switches - there's little else fundamentally in there doing anything at all other than something causing the first switch to cycle between on and off states and cascade to all the rest (this isn't entirely accurate but it's close enough to make te point).

This gives rise to situations where in order to create greater levels of complexity, lots of unintuitive, and seemingly even pointless things need to be done. For example: assigning letterbox addresses to every discrete portion of memory. Then things like "I want to read the values from this part of memory up to this part" require laboriously adding 1 to a value (a pointer) that tracks which address the computer is currently "thinking" about. It's so stupid it needs to remember where it is all the time like this, or it can't do anything.

Because C is very close to this mundane and laborious fundamental architecture, it (usefully in that case) deals with concepts like "pointers".

In languages at just a bit higher level, the language internals deal with pointers so that we as programmers don't have to.

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

#44

Post by ricardobayes »

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…

Like my professor used to say, if you ever saw a pidgeon, you know what vectors are.

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

#45

Post by transient_47 »

I stumbled upon this gem a while ago [0] while looking for a decent tutorial and reference to C:

Stuff that should be avoided: [...]

Beej's Guide to C: http://beej.us/guide/bgc/output/html/singlepage/bgc.html

Full of mistakes.

[...]

Could someone confirm this? I've seen a lot of threads here on HN praising beej's guides so I am somewhat confused.

[0] http://www.iso-9899.info/wiki/Main_Page

edit: Formatting

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

#46

Post by determinateproc »

transient_47 wrote: post #45

I stumbled upon this gem a while ago [0] while looking for a decent tutorial and reference to C: Stuff that should be avoided: [...] Beej's Guide to C: http://beej.us/guide/bgc/output/html/singlepage/bgc.html Full of mistakes. [...] Could someone confirm this? I've seen a lot of threads here on HN praising beej's guides so I am somewhat confused. [0] http://www.iso-9899.info/wiki/Main_Page edit: Formatting

Beej himself lists this as an 'alpha-quality document' on the download page [0] and if I remember correctly, it has been so for years. Wonder why this is posted here on HN.

[0]: http://www.beej.us/guide/bgc/

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

#47

Post by AlbertoGP »

qsort wrote: post #30
bluetomcat wrote: post #26

Earlier quoted context omitted.

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…

I’m actually implementing that right now for my own use, as a pre-processor.

There is a much more advanced design and implementation at “A defer mechanism for C” (December 2020): https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...

For my own purposes, I think I can live without handling stack unwinding so I continue working on my pre-processor.

Since the pre-processor is not yet finished, there I use a vector¹ of {.pointer, .destructor} where I put objects after initialization, with one macro at the end of each managed scope that calls the destructors for that scope in reverse order, then another macro meant for the function exit points that calls all the destructors in that vector. This has been built many times before by other people of course, it’s just an exercise to see which difficulties arise.

¹ Vector, growable array: I did my own trivial type-generic growable array, with the classic {.capacity, .len, .items}, but again there are many previous implementations. The two I’ve found more interesting are:

- “C Template Library (CTL)”: https://github.com/glouw/ctl

- “Klib: a Generic Library in C”: https://github.com/attractivechaos/klib/

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

#49

Post by [deleted] »

transient_47 wrote: post #45

I stumbled upon this gem a while ago [0] while looking for a decent tutorial and reference to C: Stuff that should be avoided: [...] Beej's Guide to C: http://beej.us/guide/bgc/output/html/singlepage/bgc.html Full of mistakes. [...] Could someone confirm this? I've seen a lot of threads here on HN praising beej's guides so I am somewhat confused. [0] http://www.iso-9899.info/wiki/Main_Page edit: Formatting

[deleted]

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

#50

Post by kaba0 »

serial_dev wrote: post #42
unwind wrote: post #28

Earlier quoted context omitted.

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.

It's also similar in Java's pass-by-value vs pass-by-reference (pass as well as copy), if I recall correctly.

Actually, most languages only have pass-by-value, being “pedantic” (but it is actually a useful distinction). I’m sure there are other’s but out of the majorly used languages, only C++ has actual references. Pointers are passed by value, that is the pointer value gets copied. References are a language level construct.

Here is a great “rant” at it in case of Java:

http://www.javadude.com/articles/passbyvalue.htm

Post reply on HN