Live data from Hacker News

Beej’s Guide to C Programming [pdf]

beej.us

101–110 of 178 posts

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

#101

There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.

Yes, usenet was huge for me back in the early 90s when I had questions on C programming. I would ask them on comp.programming.c and had some of the best programmers providing guidance. Of course they were strict with questions/discussions being specific to ANSI C.

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

#102

Earlier 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 As long as you’re taking, and using, the address of that variable, it’s almost guaranteed to be in memory. Even if it won’t, the compiler guarantees the output of the program will be equivalent to unoptimized code. > arguments will not be passed via the stack I’m not sure explaining nuances of various calling conventions, and…

See my reply to your sibling comment. I wasn't proposing adding more irrelevant detail. If anything, I was proposing removing the existing irrelevant and incorrect/very incomplete detail.

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

#103
post #30

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…

It’s not standardized, but if you’re using gcc, you can use the cleanup attribute for this: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...

IIRC clang implements it as well, but I wasn’t able to find a reference to it in their docs.

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

#104

There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.

I bought that book ages ago. Good stuff. comp.lang.c still has a small group of knowledgeable regulars, but a lot of the "old guard" seems to have stepped away. And Usenet is a shadow of its former self, obviously.

Reddit has more traffic nowadays.

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

#105

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/

I recently overhauled it in a big way.. er, "am overhauling it".

And I'm sure it's full of mistakes. It's over 500 pages, most of which has yet to be edited, so if there are fewer than 1000 defects, I'd be shocked.

But I fix them all as I find them, or as they're pointed out. And after an eventual editing pass, things will be better.

And if it's not useful to someone, I take no offense I'd they don't like it. :-)

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

#106
post #30

Earlier quoted context omitted.

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 ve…

With a bit of trickery CTL works much like the STL, in that containers can be built of containers:

    #define P
    #define T int
    #include 

    #define T vec_int
    #include 
A deq_vec_int - analogous to std::deque> - is a neat example.

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

#107

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

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's a tough line between intro and The Rabbit Hole. But I'll see what I can do there.

Appreciate the feedback. Some good suggestions here that I'll add.

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

#108

Beej's Guide to Network Programming helped me survive a grad-level computer networking class as a naive undergrad in college. If his guide to C is anywhere near as good it should be an awesome resource.

The C Guide is still rough around the edges (and even some in the center). But I'm working on it! :-)

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

#109

There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.

[deleted]

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

#110

There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.

#c on EFnet!
Post reply on HN