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

131–140 of 178 posts

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

#131

Post by thrwaeasddsaf »

Const-me wrote: post #99
tom_mellior wrote: post #62

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…

> One has to stop somewhere, and this article decided to stop at C, as opposed to assembly.

As soon as you mention the stack, you've gone beyond C and started talking about something that is not C.

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

#132

Post by deckard1 »

ryl00 wrote: post #77
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.

This is one part (of many) of perl that I like, that it exposes the pointer-y parts to the programmer (to abuse :)) # hash my %a = ( 'one' => 1, 'two' => 2 ); my %b = %a; $b{ 'two' } = 99; # prints 2 print $a{ 'two' }, "\n"; # reference to hash my $a = { 'one' => 1, 'two' => 2 }; my $b = $a; $b->{ 'two' } = 99; # prints 99 print $a->{ 'two' }, "\n";

The real difference is Perl has typed variables, such as hashes or arrays, which other languages typically do not. Which does make it convenient when you need to clone the object, such as "%b = %a" example. Perl borrows the sigil concept from Bash and other shells (which makes sense, given the historical context of Perl). The only other language I know of that uses sigils in such manner is BASIC. Other languages, such as Ruby or Common Lisp, use them as syntactic convention rather than as a feature that the compiler/interpreter understands.[1]

Most dynamic languages expose the data as references. In fact, the one thing that trips up JavaScript developers (especially in React) is that they do not understand how references work. I see senior and lead developers inadvertently doing mutation all the time. Or getting incredibly paranoid that two identical strings, for example, do not equal each other in the strictest sense in JS. They also throw in memoization everywhere due to their fundamental lack of understanding.

You can always tell the developers that do not have C/C++/Pascal experience.

[1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)

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

#133

Post by thamer »

gnuvince wrote: post #96
signa11 wrote: post #27

Jens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.

What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?

Apart from the new features added in C11 or C17 that others have mentioned, both Beej's Guide and Modern C also cover threads and string encoding (neither of these topics are covered in K&R 2nd edition, as far as I remember). Beej's Guide also has a section on internationalization and one about date/time handling.

But yes, the code is also quite different than in K&R which is relatively terse. See for example this comment in K&R about strcpy on print page 105 (page 119 of the PDF)[1], where after showing two versions of strcpy that are pretty readable and easy to follow, the book says:

> In practice, strcpy would not be written as we showed it above. Experienced C programmers would prefer

    void strcpy(char *s, char *t)
    {
        while ((*s++ = *t++) != '\0')
            ;
    }
Followed by a paragraph saying the condition could be simplified, and that

> the function would likely be written as

    void strcpy(char *s, char *t)
    {
        while (*s++ = *t++)
            ;
    }
Make of that what you will :-)

[1] https://kremlin.cc/k&r.pdf#page=119

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

#134

Post by unfocused »

beej71 wrote: post #120
determinateproc wrote: post #92

Earlier quoted context omitted.

On further observation the git repository of the book [0] seems to be quite active. Maybe this book might be finished after all. [0]: https://github.com/beejjorgensen/bgc

Backstory: I started writing this book for novice programmers about 15 years ago. It was going to be a lot shorter. But I became disinterested because: 1. Most beginning programmers don't start with C 2. I wouldn't get a chance to go deep and explore the language. So I shelved it, unfinished. Flash forward to about a year ago... I had flash of inspiration: change the audience to intermediate programmers. Now I could…

Just wanted to say THANK YOU as I read your guide to network programming way back in 2000, over 20 years ago! I was just starting out in C network programming on VxWorks :) Glad to see you're still updating your guides.

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

#135

Post by 3rly »

I see a lot of people making opinions that clearly shows that they have not audited the entire guide. For the intended audience that the author wanted to reach. I will say that he accomplished it.

For anything that one finds as mistakes, the author went out of his way (via references) for the reader to dig further.

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

#136

Post by fctorial »

potbelly83 wrote: post #97
signa11 wrote: post #27

Jens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.

Nice book. As a C++ programmer how much of its discussion related to C's storage/memory model would carry over to C++?

All of it. C++ is a superset of C.

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

#137

Post by fctorial »

beej71 wrote: post #120
determinateproc wrote: post #92

Earlier quoted context omitted.

On further observation the git repository of the book [0] seems to be quite active. Maybe this book might be finished after all. [0]: https://github.com/beejjorgensen/bgc

Backstory: I started writing this book for novice programmers about 15 years ago. It was going to be a lot shorter. But I became disinterested because: 1. Most beginning programmers don't start with C 2. I wouldn't get a chance to go deep and explore the language. So I shelved it, unfinished. Flash forward to about a year ago... I had flash of inspiration: change the audience to intermediate programmers. Now I could…

> Most beginning programmers don't start with C

Except literally every indian engineer. They teach C to mechanical and chemical engineers for some reason. (It's not an elective)

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

#138

Post by GeorgeTirebiter »

fctorial wrote: post #136
potbelly83 wrote: post #97

Earlier quoted context omitted.

Nice book. As a C++ programmer how much of its discussion related to C's storage/memory model would carry over to C++?

All of it. C++ is a superset of C.

Others disagree: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html

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

#139

Post by tirrex »

AlbertoGP wrote: post #47
qsort wrote: 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…

For a vector alternative, I find this one easy to read and use :

https://github.com/tezc/sc/tree/master/array

It is just an array of your type, e.g int *numbers, so you have type info in debugger as well.

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

#140

Post by Arch-TK »

GeorgeTirebiter wrote: post #138
fctorial wrote: post #136

Earlier quoted context omitted.

All of it. C++ is a superset of C.

Others disagree: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html

You don't really have to ask others. The C and C++ standard disagree, you can easily find instances of this disagreement if you just peruse them. The easiest example to find is the difference in behavior of the auto keyword or in how conversions from void * to something_else * are implicit in C not in C++. There's now also an extreme number of subtleties in terms of undefined behavior which differ between the languages.
Post reply on HN