Example: http://www.cs.stanford.edu/cslibrary/PointerFunCBig.avi returns 404. :(
Does 'advanceed' mean 'more advanced than advanced?' [1]
Although some feel like it’s too opinionated to belong in this article I really appreciated the above. Edit To be clear the author is advocating for simpler syntax here to increase program readability. This could be taken other ways.
Ugh. He's talking about inline use of post-increment and pre-increment (i.e. x++ and ++x) here. This is perfectly readable to a C programmer, and sidestepping them actually makes the code harder to understand.
for(i=n; i-- > 0 ;)
{ /* operate on a[i] */ }
x = *stack--; // pop 'x' off of the stack
*++stack = y; // push 'y' onto the stack
https://www.youtube.com/playlist?list=PLhQjrBD2T381L3iZyDTxR...
Sure it doesn't get in details about the language but you get the essential and the videos are great.
Topics:
* Best practices for C function signatures (caller allocates (which size?), callee allocates (where? which allocator?))
* Memory Ownership Models
* Borrowing
* Reference Counting
* Garbage Collectors and C-Libraries providing this functionality
* Interning Objects (Strings)
* RAII [1]? And it's benefits/flaws
[1] https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
Context: I feel that understanding the C memory primitives in not that hard (stack variables, malloc/free, C++'s new). But how to use them is devilishly tricky. I have seen little information about this.
This generally discusses the lack of RAII in C (towards the end), and what to do about it:
https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
...and this presents a (reasonably runtime-safe) general memory management strategy using tagged-index-handles instead of pointers:
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
The gist is basically:
- don't allocate small chunks of memory all over the code base, instead move memory management into few centralized systems, and let those systems own all memory they allocate
- don't use pointers as public "object references", instead use "tagged index handles"
- don't use "owning pointers" at all, use pointers only as short-lived "immutable borrow references"
A previous HN discussion on that book:
https://news.ycombinator.com/item?id=15624521
EDIT: That earlier discussion has an excellent first post. Quoting:
"It bothers me so much that very few books (Kernighan) talk about WHY. WHY. WHY is a variable needed? WHY is a function needed? WHY do we use OOP? Every single book out there jumps straight into explaining objects, how to create them, constructors, blah blah blah. No one fricking talks about what's the point of all this?
Teaching syntax is like muscle memory for learning Guitar. It is trivial and simply takes time. Syntax - everyone can learn and it is only one part of learning how to code. Concepts are explained on their own without building upon it.
[... A list with learning resources the poster finds great ...]
This is learning how to produce music. Not learning the F chord. Teaching how to code is fundamentally broken and very few books/courses do it well."
I never really got to a point of learning Haskell or Lisp up until recently, it was always this --- I can do everything with C/C++/Java/Python and I could. But the thing is it is only after learning lisp that I really got the hang of thinking in top down manner(recursively), or for that matter it took Haskell to teach me composition intuitively, which then could be extended to my main language(C++). I understand that syntax doesn't matter much, but fwiw I still think in terms of lisp syntax when writing recursive code in C++/C. So yeah, take that for you will.
> In particular, if you are designing a function that will be implemented on several different machines, it is a good idea to use typedefs to set up types like Int32 for 32 bit int and Int16 for 16 bit int.
Use <stdint.h> please
> The char constant 'A' is really just a synonym for the ordinary integer value 65 which is the ASCII value
Not always, especially right after you came off a paragraph explaining how different machines have implementation-specific behaviors
> The compiler can do whatever it wants in overflow situations -- typically the high order bits just vanish.
This is a good time to explain what undefined behavior actually means
> The // comment form is so handy that many C compilers now also support it, although it is not technically part of the C language.
Part of the language since C99
> C does not have a distinct boolean type
_Bool since C99
> Relying on the difference between the pre and post variations of these operators is a classic area of C programmer ego showmanship.
I'm fine with you mentioning that this can be tricky, but this is more opinion than I am comfortable with in an introductory text
> The value 0 is false, anything else is true. The operators evaluate left to right and stop as soon as the truth or falsity of the expression can be deduced. (Such operators are called "short circuiting") In ANSI C, these are furthermore guaranteed to use 1 to represent true, and not just some random non-zero bit pattern.
Under the assumption that there are no boolean types from earlier, this is not true
> The do-while is an unpopular area of the language, most everyone tries to use the straight while if at all possible.
I would argue that people use do-while more than they need to
> I generally stick the * on the left with the type.
Not a problem, but :(
> The & operator is one of the ways that pointers are set to point to things. The & operator computes a pointer to the argument to its right. The argument can be any variable which takes up space in the stack or heap
And constants/globals
> To avoid buffer overflow attacks, production code should check the size of the data first, to make sure it fits in the destination string. See the strlcpy() function in Appendix A.
strlcpy is non-standard and probably not what you want
> The programmer is allowed to cast any pointer type to any other pointer type like this to change the code the compiler generates.
> p = (int * ) ( ((char * )p) + 12); // [Some spaces added by me to prevent Hacker News from eating the formatting]
Only in some very specific cases…
> Because the block pointer returned by malloc() is a void* (i.e. it makes no claim about the type of its pointee), a cast will probably be required when storing the void* pointer into a regular typed pointer.
Casting malloc is never required (and I would say usually not a good thing to do)
> Under the assumption that there are no boolean types from earlier, this is not true
Actually, I believe _Bool is guaranteed to use 0 for false, and any non-0 value is stored as 1 for true. Arithmetic on _Bool is also guaranteed, based on those values.
For example, I believe the standard guarantees:
_Bool x = 255;
assert(x == 1);
size_t y = 10 + x;
assert(y == 11);> Not a problem, but :(
In a declaration, * is a type modifier. E.g. `int a;` declares a variable of type "int" named "a". `int* a;` declares a variable of type "pointer to int" named "a".
The only time this doesn't work is if you stick multiple declarations on the same line. That's annoying to me, because it means you're breaking the "declare variables as close to their first use as possible" practice. It's not K&R C any more, you don't need to declare everything all at once at the top of the scope.
Also, to prove that `` in a declaration is part of the type, note that K&R style function declarations (no argument names, just types) are still valid C (though I'd strongly discourage their use). So `void func(int a, int b);` is identical to `void func(int, int);`. It's very different from `void func(int, int);` that you'd get if you assume the `` goes with the `a`.
Can you elaborate on this one? I thought && and || expressions always evaluated to 0 or 1.
Converting any scalar value (that includes pointers) to _Bool yields 0 or 1 (false or true).
https://www.amazon.com/Primer-Plus-5th-Stephen-Prata/dp/0672...
My version was older than the Amazon version as I learned in 1987.