Just found out that it has an actively maintained GitHub repository, with 35 or more commits this April alone.
https://github.com/beejjorgensen/bgc/commits/main
Beej’s Guide to C Programming [pdf]
81–90 of 178 posts
Re: Beej’s Guide to C Programming [pdf]
#82Earlier quoted context omitted.
On a quick skim of some introductory parts I found: > When you have a variable in C, the value of that variable is in memory somewhere, at some address. Of course. After all, where else would it be? It would be in a register. Of course. Or it would be eliminated by a compiler optimization. Of course. Same error later on: > When you pass a value to a function,a copy of that value gets made in this magical mystery worl…
> It would be in a register. Of course. Or it would be eliminated by a compiler optimization. Of course. Since you mention relevance for beginners later on in your post I'd argue this isn't relevant either. This concept holds true for simple code that doesn't do advanced stuff like working with hardware. As soon as you do &variable, you get an address and can work with it. If the compiler optimized something away you…
> Since you mention relevance for beginners later on in your post I'd argue this isn't relevant either.
Agreed. At the time that variables are introduced, it should just say "a variable is a name for a location where a value is stored". I didn't mean to suggest that the tutorial should go into needless detail at that point. Just that the needless detail that it currently goes into is wrong.
> Same with passing variables via stack.
Again, my problem is just with the needless detail. When you pass a value it is copied (that is the relevant part) somewhere where the callee can find it (that somewhere is the irrelevant part).
Re: Beej’s Guide to C Programming [pdf]
#83Earlier quoted context omitted.
That's why I tend to always prefer automatic and static storage to dynamic allocation wherever possible, especially in cases where you don't have "N" items or "N" cannot possibly exceed a certain small value. Also, allocation/deallocation of the certain object need not be defined within its module. It should be up to the caller to decide whether to allocate the object on the stack, statically or dynamically depending…
Interesting, I tend to prefer a create and destroy function that allocates and frees the structure. That way you can have foo without it being initialized, and you cant have foo been freed without being de-initialized. Where do see the value in being able to move it between different memory types?
In games and embedded systems, a very common pattern is batched heap allocation: a single allocation of an array of foo, and/or an array of foo mixed with other types, or sometimes a memory managed data structure like a memory pool. This is one big reason that the C++ Standard Template Library was shunned in game studios for a long time; it automatically did it’s own heap allocations, sometimes at inopportune times IIRC like in constructors, and didn’t let the caller choose. EA wrote their own version (EASTL) that was game friendly because it allowed control of the allocator.
In GPU programming, there are actual different memory sub-systems, with different sizes and different performance implications, so it’s critical that the caller is able to do the allocation & deallocation any way they want. This is why most well designed GPU APIs rarely allocate GPU memory inside the API, but instead are designed to work with caller-provided pointers to buffers.
Re: Beej’s Guide to C Programming [pdf]
#84Earlier quoted context omitted.
There's actually a logic to it, although not an intuitive one at all, and it's that declaration should follow use. That is `int *ptr;` is a pointer to an int and to get the int you have to use * on it.
But int-pointer is the type of it. It makes no sense that it “sticks” to the variable name.
int * a, b;
Then typedef comes along and ruins everything:
typedef int * pint;
pint c, d;Re: Beej’s Guide to C Programming [pdf]
#85Earlier quoted context omitted.
There's actually a logic to it, although not an intuitive one at all, and it's that declaration should follow use. That is `int *ptr;` is a pointer to an int and to get the int you have to use * on it.
But int-pointer is the type of it. It makes no sense that it “sticks” to the variable name.
The reason the asterisk naturally "sticks to" the name is simply the possibility to write a series of declarations like this:
int a, *b, (*c)(int);Re: Beej’s Guide to C Programming [pdf]
#86I 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/
I think posts like this are handy just for the extra exposure an alpha document might need; there's a lot of good feedback and discussion here that hopefully beej comes across someday and can finish the book
Re: Beej’s Guide to C Programming [pdf]
#87IMO, 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…
For anyone who wants to learn about pointers I can recommend studying a language simpler than C like for instance Oberon where pointers are more restricted. Having a look at Oberon can also broaden your view even if you know pointers in C. https://www.miasap.se/obnc/oberon-report.html http://people.inf.ethz.ch/wirth/Oberon/PIO.pdf
Actually, this could confuse things even more, because the C pointer and Oberon's POINTER TO have very little in common.
Re: Beej’s Guide to C Programming [pdf]
#88IMO, 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 are like swazzles[1]. The construction is very simple. The principle behind how they work is very simple. Learning how to use one well enough that you can (a) consistently make it do what you want, and (b) not injure yourself in the process, though, is no mean feat.
[1] https://www.atlasobscura.com/articles/swazzle-punch-and-judy
Re: Beej’s Guide to C Programming [pdf]
#89Jens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.
Jens Gustedt is a co-editor of the ISO C standard, so he knows his shit. Modern C is probably the best book about modern C, short of reading the standard.
It's far easier to read than the standard, too, since it's explanatory rather than declaratory. The standard tells you what C can do, Modern C teaches you how.
Re: Beej’s Guide to C Programming [pdf]
#90Earlier quoted context omitted.
Interesting, I tend to prefer a create and destroy function that allocates and frees the structure. That way you can have foo without it being initialized, and you cant have foo been freed without being de-initialized. Where do see the value in being able to move it between different memory types?
Coming from the embedded world, I am far more used to the style bluetomcat showed where the caller handles allocation. It takes more work to use, and you have to make sure to not use it before initializing or after destroying, as you said. The advantage is that the caller has full control of memory allocation. The object can be a local variable, a static, malloc:ed, come from a custom allocator (say a slab allocator)…
That makes a lot of sense. I do some embedded development, but when I dont, I tend to prefer heap just because my memory debuggers are much more capable working with heap memory.
In the case you show, foo would have to be a struct that doesn't contain pointers to additional allocated memory, but its a entirely valid use case and pattern.
Calling malloc and free, has a cost associated with it, that the stack doesn't. But stack can in some cases, like with recursion be scary to use, because you dont know where it ends. If malloc returns NULL you know you have found the end and can do something reasonable.
Thanks for you insight!