How I program C

"In the beginning you always want the results. In the end all you want is control." These two lines more or less sum up my 10 years of programming experience.

0:00 intro 5:00 garbage collection is not suitable for high performance scenarios 6:20 prefer stable & concise language features & technology stack 8:25 avoid ambiguity 11:00 don't be "clever" 11:45 be explicit 14:40 static-type language can catch more errors 16:00 early crashes are better than hidden bugs 17:30 improve your developing tools 20:20 general naming convention & coding style 27:20 prefer imperative & sequential code, long functions are OK 31:40 function naming 35:20 API design 36:00 how to organize .h & .c files 38:40 C & OOP-style APIs 41:00 void pointer is your friend to hide internal data 44:18 macros: _FILE__, __LINE_ 49:40 a custom allocator for memory debugging 53:10 macro utilities for binary data packing/unpacking 57:10 memory control & pointers 1:03:00 malloc 1:06:00 arrays 1:09:20 struct 1:11:15 inheritance via C pointer casting 1:16:35 struct packing, padding, memory alignment 1:22:55 memory pages, realloc, gflags.exe 1:33:42 memory caches 1:42:30 don't store data twice 1:45:25 trick to reduce allocations: Flexible Array Member 1:48:30 trick to reduce allocations: joint malloc (dangerous) 1:50:48 use "stride" for better handling of Array Of Struct (AOS) 1:53:15 architecture on top of small & flexible primitives 1:55:45 prefer incremental progress 2:00:00 fix code ASAP 2:01:55 UI application design 2:08:50 Carmack's fast square root algorithm 2:09:56 magical random number generator 2:10:30 closing, contacts

The only thing better than C is HolyC

Wow. this guy doesnt even use powerpoint. he uses C for slides :D.

As a beginner I can't explain how much I appreciate this video. Clear, concise and simplified without sacrificing content. I started with python and am struggling with picking up C. Learning syntax is one thing, learning HOW to apply it is another

The video is nearing 6 years, yet one of the most profound video on C programming.

I've been trying to learn C++ and have realised that C is actually the place for me

"the compiler is your friend when it tells you something is wrong." This is very true, but the problem with that is that C compilers give the least detailed or useful error messages out of any language I use, not to mention that managed languages give you actual error info at runtime instead of just "segmentation fault." Edited for clarity.

“Fuck macros!” proceeds to discuss benefits of macros for ten minutes

You are a legend! I've been writing C code for 20 years and you've taught be a few ticks I just hadn't realised until now. Thank you.

Awesome, people can dislike, trash all they want but, how many videos like this you see out here? You wanna watch a video on how pointers work? Linked lists? This is real life code and it's awesome that someone took the time to do a video like this. Congrats, man!

I come back to this presentation from time to time. It's given me some good ideas for my own work. Thanks!

This is fantastic. So much experience condensed into an easily digestible format. Thank you for sharing! Having a bit of (theoretical) background in C and C++, just from reading mostly, I've always been hesitant to work in C. Most of that hesitation comes from what I learned in school about OOP and all the do's and don'ts. I've already started doubting much of that since, I always felt it made programming so much harder than it had to be and your video just gave me that extra push.

"Typing is not a problem" proceed to make lots of typo LOL but I agree, that's why we have an editor

It's amazing how many things one can know about programming and still have 0 idea how to spell basic words. And I mean this as a compliment. You don't waste your time learning things which don't matter to you.

Thank you for this. I wish there was more of this kind of content available, but nowadays it's full of "Learn X in 2 hours", "How to make a CLI tool in X", etc. This was something I watched closely and took notes.

This boosts my self esteem to program in a way that !not strictly uses design patterns, but the way you understand best! Thanks for sharing!

Nobody overloads the multiplication with vectors. Every math lib I saw uses explicit names: dot, cross, scale. The * operator is sometimes used to multiply a vector by a scalar (uniform scale) but that's all. C++ programmers are less dumb that you think.

1:42:00 - If you already know the index to remove, you can just use memmove. It's much faster than most people realize because it will invoke SIMD operations and hardware intrinsics to move multiple chunks of memory per cycle. It can actually be faster to memmove an array to remove an element than to remove an element from a linked list using pointer reassignment. Pointers can make things very slow if they aren't used correctly.

12:15 Not a compelling argument at all in my opinion. Operator overloading mostly makes sense when it's used to define real mathematical operators. (With the exception of string concatenation i guess, and maybe other types) Operators ARE functions. They take data in, they spit data out. If you're smart enough to understand that "strcat" concatenate two strings together, you're smart enough to understand that '+' concatenate two strings together. Its just another notation to mean the exact same thing. Using the example of vector multiplication is dishonnest : its ambiguous because there's no clear definition of what a multiplication of vector is. Not because '*' is not explicit in and of itself. And that's why half the people say parwaise mult, and the other half say dot product : They don't know because there's no good anwser. In fact, i'd like for you to elaborate on why you think "mult_vec (&vecA, vecB, vecC)" is somewhat more explicit than "vecA = vecB*vecC". there's no sementic difference between them... they mean the exact same thing. They're Just written differently. Therefore if "mult_vec" is explicit, so is '*'. I suppose you DO use operators on primitive data types ? Why ? Why are they explicit enough ? Because you know what '+', '-', '*', '/', '%' mean on numbers. In reality, no operator is explicit. You *HAVE* to know what they do to know what to expect from them. If I'm able to know what an operator does to primitive data types, I don't see why I wouldn't be able to do the same for other data types.