61–70 of 178 posts
it actually has working examples for all of the C library calls even math routines. Not sure if it's complete but it seems so. This seriously helps bridging the gap between man (2) pages and putting things into working code and only beef I have is that I didn't have it 25 years ago. Very cool.
Nit: most of the C library calls are in section 3; section 2 is system calls.
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
> 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 world known as the stack
No. In most common cases, arguments will not be passed via the stack. This goes on to clarify in a footnote that the implementation might not actually use a stack, and that the stack has something to do with recursion. That part is true, but the values saved on the stack for recursing are not the same as function arguments.
Neither in the Variadic Functions chapter nor anywhere else are the default argument promotions mentioned -- this will bite someone who tries to write a variadic function that gets floats out of the variadic argument list, which you cannot do, since passing a float to a variadic function promotes it to double.
Speaking of floats... This is one of those tutorials that are very confused regarding their target audience. For example, in the "Variables" section it goes out of its way to define: "A “byte” is an 8-bit binary number. Think of it as an integer that can only hold the values from 0 to 255, inclusive." (which isn't the C definition, but this really is nit-picking) but then happily goes on to talk about Booleans and floats without explaining what those are. What reader has a background that would make this useful?
Overall, from the little I've seen, I'd give this an initial rating of "broadly correct but with definite mistakes".
Even if it were fully correct, I dislike the verbose style, and I wouldn't recommend this tutorial. For example, in the Hello World chapter, we have the following "explanation" of the line "#include ":
> Now, what is this#include? GROSS! Well, it tells the C Preprocessor to pull the contents of another fileand insert it into the code rightthere.Wait—what’s a C Preprocessor? Good question. There are two stages (well, technically there are more thantwo, but hey, let’s pretend there are two and have a good laugh) to compilation: the preprocessor and thecompiler. Anything that starts with pound sign, or “octothorpe”, (#) is something the preprocessor operateson before the compiler even gets started. Commonpreprocessor directives, as they’re called, are#includeand#define. More on that later.Before we go on, why would I even begin to bother pointing out that a pound sign is called an octothorpe?The answer is simple: I think the word octothorpe is so excellently funny, I have to gratuitously spread itsname around whenever I get the opportunity. Octothorpe. Octothorpe, octothorpe, octothorpe.Soanyway. After the C preprocessor has finished preprocessing everything, the results are ready for thecompiler to take them and produceassembly code8,machine code9, or whatever it’s about to do. Don’t worryabout the technical details of compilation for now; just know that your source runs through the preprocessor,then the output of that runs through the compiler, then that produces an executable for you to run. Octothorpe.What about the rest of the line? What’s? That is what is known as aheader file. It’s the dot-hat the end that gives it away. In fact it’s the “Standard I/O” (stdio) header file that you will grow to knowand love. It contains preprocessor directives and function prototypes (more on that later) for common inputand output needs. For our demo program, we’re outputting the string “Hello, World!”, so we in particularneed the function prototype for theprintf()function from this header file. Basically, if we tried to useprintf()without#include , the compiler would have complained to us about it.How did I know I needed to#include forprintf()? Answer: it’s in the documentation. Ifyou’re on a Unix system,man printfand it’ll tell you right at the top of the man page what header files are required. Or see the reference section in this book.:-)Holy moly. That was all to cover the first line! But, let’s face it, it has been completely dissected. No mysteryshall remain!
Only one sentence of this is relevant for an introductory Hello World chapter: "Basically, if we tried to use printf() without #include , the compiler would have complained to us about it." None of the rest is relevant or helpful to a beginner who is just seeing their first ever C program. Also "completely dissected" isn't true either; there is a lot more to be said about headers.
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.
I agree, which is why I'm glad the first language I learned was C. I don't get to write a lot of C at work, but the concepts the language teaches you are the very fundamentals of programming. I know it's probably baseless, but I can't shake the feeling that people who learn modern languages before learning C are just making their own lives harder.
[0] https://www.instructables.com/CARDIAC-CARDboard-Illustrative...
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…
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 never use you might as well just pretend it's in memory somewhere for the sake of a mental model that's easy to grasp. Same with passing variables via stack. A simple compiler could do it just like that.
That isn't to say the tutorial is good/not good, but these points in particular seem rather sane to me. Far from "Mastering C Pointers" at least :)
Earlier 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.
When using that variable with the allowed operators, the resultant type of the expression is determined by the declaration:
pa; // int *[10]
pa[x]; // int *
*pa[x]; // intJens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.
Earlier 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.
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!
http://pythontutor.com/c.html#mode=edit
If you click down to the bottom and choose from the examples "Pointer Levels" you'll get a good idea of the tools powers.
Earlier quoted context omitted.
Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) https://www.amazon.com/Programming-Language-2nd-Brian-Kernig... Also, there's nothing magical about pointers - scripting languages use "handles", which is the same thing except they're read-only to the end-user programmer. The real challenge with C is multi-threaded programming, so don't do that if you don't need i…
> Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) This is really an amazing feat: books on programming languages age really fast. This one - not so much. And you can really appreciate the careful thought that was put in each sentence. Peerless. > The real challenge with C is multi-threaded programming, so don't do that if you don't need it. Well, these days it's…
There was some article a few years ago that said the apps they looked at didn't actually run faster after making some routines parallel, so it depends, and you will definitely have more debugging to do.