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.

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

The only thing better than C is HolyC

pretty dissapointing video, no indian accent

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!

Keep coming back to this video. Such a gem.

I would advise anyone to take this with a grain of salt. It's a good talk and there a lot of valid points made, but I suggest not to take everything he says as ground truth. There are millions of productive programmers in the languages this guy is effectively calling "inherently wrong". And many smart minds who have designed them. You have to find and use what works for you, not what works for someone else.

Content with very skilled competence. After 18 month of C++ and writing two relation databases and tons of training code, I realize, that C must be the future for me. I’m hoping Eskil is making more talks about C. It’s is gold and super interesting. The parts with structs, pointers and memory management is fantastic and explained very well!

You know its good when you enter the video and see controll

Dude this is how teaching should be. I been really trying to innerstand the concept of what code is doing and why numbers are needed. Why why why. Thank you man ❤

23:32 On this point, most IDEs or even text editors have a "match whole word" option when searching, which looks for word boundaries when searching. This removes the issue of searching "my_function" and getting "my_function_with_stuff" and also works for other types like variables.

1. About function overloading, I do actually prefer c++ here, as it has a way to specify the type, and be less cryptic about it. It's literals for when that is available or explicitly calling type constructors when not. There is an argument as this is not enforced and implicit type conversions may cause a bug, but when you need it, providing argument type with the arguments themselves, instead of in the function name will force you to change them once you want to edit the function call. As a benefit, you also get arguments types as part of function signature which helps a lot with naming, as while it is good to be explicit, and not have ambiguity, going too much in that direction will lead to code becoming white noise, and it's much harder to not make mistakes, or miss anything while reading. 2. I agree crashes are good, but to me it's obvious that compile time errors are strictly better. Love the video otherwise

After you said thing.Hello in "Java script" returns 0, I actually considered keeping track of how many inconsistencies or flat out wrong statements there were in this video, but then I realized that was just 15 minutes into the video.

I love this talk a lot. Watched it a year or two ago when I was starting out moving over to c from c++. Just re-watched it after actually getting into a c opengl project pretty good. Got a lot more out of it this time. I really agree with your philosophy and found myself doing a few of these "wrong". Gonna incorporate some of these tips. Cache friendly main loop is still eluding me. Thanks for all the sharing you do.

I started with C and then went to Python. I actually felt uneasy with Python right away because it felt like I had no idea what was going on half the time and stuff was happening by magic. 😅

Nice overview Eskil! I found that people who love C are people who know their hardware. I am one for sure :).

I have exactly about 5 weeks coding with C. I hadn't coded in 8 years. I don't have much education but about 25 minutes into your video and I do most of the things you have said are good. Made me feel really good even though I really struggled with pointers. I'm doing C Primer Plus by Stephen Prata page by page. After it I'm doing a book that's only about pointers in C. It has good reviews so I hope after that I'll be a more or less decent C programmer. Very nice video though I don't agree with everything but I do enjoy getting to hear the reasoning behind your decisions.

Got back to your video after archiving it and I'm pretty pleased. Great work + love your approach!

Another thing I have picked up from this video: long functions. I have always been taught to “abstract away” and “encapsulate” things and then it becomes an easter egg hunt to find the function within the function within the function! Having however One loop like you suggest that simply does things based on conditions/state and is very clear about that and reads top down like a story book is Sooooo much easier to read when coming back to later. The problem though is that though I like it, other people don’t…

In the javascript example, it wouldn't define "Hello" nor would it be "0". It would be the value "undefined".

"Build a mountain!" This resonates with me. Thanks for creating this video!

You can't have control, the purpose of a programming language is to abstract the machine, otherwise you would write machine code directly. You are giving up control. The real question is how much. I don't want control, I want abstraction power, I'm more of a top-down designer coming from mathematics side of things. The machine does the computation for me, not the other way around.

2:08:20 this opened my eyes... this is the most clever thing i've seen in my life

Very nice talk, filled with valuable advice. Thanks for taking the time.

I think I still prefer C++ although you make some good points that I agree with. C++ tends to make things overcomplicated sometimes, a bit more verbal and somewhat cryptic but then again the thinking is different. I have a feeling that C programmers spend less time creating the structure of the program and more time debugging the program while C++ is more like taking care that you have a good structure and that you wouldn't have to debug your program much later. Some weak points that you mentioned about C++ are some of the things I fell into when I was learning it the first time but it's been pretty smooth sailing after that. I don't deal with memory leaks nowadays anymore and generally I don't really spend any time debugging my applications nowadays other than threading race conditions and things like that. Also I do dare to say that in practice C++ programs are not any slower than C programs. I think we can agree that it's mostly about preference of which one you prefer but I don't understand why you wouldn't want to write C code and let the C++ compiler handle it for you? I don't see a reason why you would want to stick to plain C while mixing it with C++ you could still program like in C but with added features like namespaces and even better C++11 constexpr, nullptr and std::swap() function. Keeping it pure C is just shooting yourself in the foot. If you're feeling adventurous a little you could try returning std::vector from a function instead of handling arrays / pointers. C++11 makes returning a temporary std::vector fast btw. And you could do all this while still keeping the functional programming style in your programs. I am genuinely curious why you would limit yourself to just plain C as you can mix all the new C++ stuff to your C style code just fine. Not that you have to reply to me but I don't accept "just evil" as an answer without some serious proof of it. You could use vector class from stl to simplify your coding and making it more sturdy, it's not like you have to start coding classes yourself. Vector class is also really simple to understand, there's nothing mystical about it, it will behave exactly the same way every time.

Currently working in unity, but i feel whatever you have to say will be worth for me to take notes off. 20 minutes into video so far and youre very well spoken especially since a noobie like me can get your point

Good video that skips HM type systems and how they overcome half of these issues while providing a good chunk of other improvements

You do have some valid points, C is definitely easier to read at a glance, and get familiar with. I guess my primary problem with this is that you say conventions are unclear and need to be studied, like vector multiplications, and then define your own conventions like typedefs being upper case, functions lower case. In the end they're also just conventions. Function documentation should be written into the source code of course. The second problem I have is that you don't seem to fully realize what's possible in other languages. Like, I think having addf(4, 0.3f) is just bad practice overall, eg. In C++ you can prevent this with compile time error if you wish, and force the user to explicitly convert types into the same type first, yes the function is going to be harder to read, but there won't be dublicate functions, and I'd argue that if you needed to look inside a function to figure out what it does, it's not named properly or its documentation is lacking. Just some thoughts.

I almost agree with everything in this video, except for the typedef void Something; Void pointers can be assigned without a cast, so you lose type checking completely here. You could pass any pointer and the compiler won't notice the error. I prefer a forward definition like typedef struct Something Something; You get type checking and still can't access the struct if it isn't defined in public header files.

1:06:49 one of my favorite cursed, weird c things is that 2[arr] == arr[2]

every programmer should know about memory segments. and if you know about memory segments, you can't "be fooled into thinking" an object is "a thing with data and code". OOP is about (good) abstractions. thing.do_something() is more natural because it corresponds to how we perceive the real world. the naming system you have going on is solid, but if it's also redundant when compared to well-defined abstractions.

The best ever sum up of good programming and C omg

I appreciate you sharing your philosophy and methods, even if I don't aggree with everything I enjoyed seeing a different perspective.

I love your religious beliefs. it sure makes life easy for the most part when programming in C.

22:37 putting a space after the function name but before the parentheses *has two use cases:* 1. When you _define_ your function it makes it trivial to find the definition in a plain text editor. (IDEs used to be slow and bloated and this was a “trick” to help navigate your codebase without the crutch of an IDE.) 2. Multi column vertical alignment can, in specific instances, help with readability when all the parentheses are aligned vertically.

24:58 "This is legal C" no it isn't. The lexer must always necessarily consume as many characters as possible to form a token, so the string of plusses is tokenized to two increment operators and a plus, but the second increment operator is not applied to an lvalue, and therefore the compiler errors out on a constraint failure.

I'd really love to see more about how your memory debugging system works, that's actually pretty cool.

That point at 31 minutes makes no sense to me. Wouldn't you want to be able to read your code flow without having to worry about scrolling through it and potentially getting lost in it? Like forgetting about some state that you set 300 lines earlier that matters later in the code?

As I'm writing this, there are already 255 comments, so... First post! (also, great video)

My only problem with C is namespacing. It is way more convenient when an IDE shows only the relevant functions for a struct/class.

A lot of the opinions in this video remind me of Andrew Kelly and his reasoning behind the zig language. Even things like making the language easy to parse. I wish more people would write code like this.

1:08:25 They are actually NOT equivalent, because the second implementation changes the value of p, the first implementation doesn't.

I started learning C a week ago or so, and this video is kind of a god sent. I feel like C is super interesting.

Bit off-topic, but I'm genuinely curious: are you dyslexic?

12:30 in GLSL/Intel/Clang/GCC vector extensions it means pairwise multiplication. So sqrt(sum(v*v)) would be the vector's length. Pairwise multiplication makes more sense, since it is just an extension of 1d multiplication to higher dimensions. Lets hope this definition sticks, and further C versions will support it out of the box.

I love the video explaining the inverse sqrt algorithm relates to the structure of a float

Regarding your object orientation section, it doesn't really make much sense. You claim that OO languages fool you into thinking that programs can have both instructions and data when that isn't the case because in computers instructions are protected... but in OO you also cannot modify instructions, it comes off as trashing on OO simply because you are unwilling to depart from a purely imperative way of thinking. Nevermind that the idea of code reflecting the way computers behave is a false dream to begin with. Nowadays even assembly is too high level if that's your rationale.

Thanks, very helpful! For your perusal at 1:46:00 you give a tip on how to allocate contiguously an array within a struct. There is another way to do it which I have seen in a presentation by Prof. Kernighan: malloc(offsetof(array, data) + sizeof(uint8)*length) . In that case the same technique is used for allocation, but the offsetof macro is implemented.

I love your coding philosiphy. Thank you, I am grateful

I like the way you think!

John Carmack didn't come up with the fast inverse square root algorithm - you can see the history on the wiki. IIRC, the cool thing was that constant is from a paper that tabulated great initial guesses for newton iterations so it only needs to do one iterations before converging

You will need to turn every volume knob up to hear this.

How do you feel about Rust? It seems to be a language designed around the same ideas you're presenting. In the four years since you've posted this, the language seems to have become extremely robust, while remaining simple.

Awesome teaching ❤️ 👏

I'm a bit late to the party, but thank you for this video! I hope you start creating content again. :)

I have a higher level language background and now try to learn c , but for just hobby, because no company i work use c, i just want to learn deeper about CS.

There are so many topics in C . Just finished with cryptography and now doing sockets and threads

You should be very proud of your skills in C and a very well made video! I do have to say that since using Rust, I think that is the direction programming needs to head towards, and mostly for the very reasons you like C. Compiler errors are absolutely your friend, and Rust out of the box gives possible the best error messages I've ever seen. Not just a file, line number, and context, but even the exact characters that potentially caused the issue. Unambiguous code is the best code, but verbose code can obfuscate intent. Rust infers intent from the programmer, but only at compile time, and only when it is entirely unambiguous. The directory structure you've added to your function names to ensure readability? Replace those underscores with double colons and you're at Rust's module and implementation system. Data being separate from code? Absolutely. Even operator overloading is forbidden in Rust. If you want to redefine how comparison operators work on an abstract structure, you define how comparison works explicitly, not how ,>=,

44:15 ... ... bro.... what? Macros have a whiff of C++ in them... ... you're daffed. Also I like how you go on to say that debuggers can't debug macro prossessed code for shit, and but with the __Line__ macro, you can accomplish GLORIOUS DEBUGGING XD. You make mess of macros, and you call it "beautiful code" ... right after you said you don't like macros you don't use them, they have a whiff of C++. You criticize the fuck out of C++ and then you talk about being careful of memory management pitfalls like leaking memory.... Mate, MATE.... do you not realize what the whole point of smart pointers is? We don't bother to manually specify memory management, we avoid that whole foot gun... by hand off responsibility through levels of abstraction... the problem with C++ is that it's socially obligated to maintain a level of backward compatibility to the antiquity of C99.... that's the problem with C++, it's the whiff of C in it! You fuck'n... aauuugh! AAUGH! So you fix the debugger by padding all your data with commentary.... so you can look at the memory and find out what is what.... yeah.... you know what else does that.... static analyzer information and modern runtime debug tools. You know... all the development of the programming workflow that took place over the last quarter century, you freak'n CAVEMAN. I love how at one point you're like "now this is actually a macro not a function, even though it looks like one, see hold on... let me find my debug file... where did I put it...." and then you find it in an include processor directive at the BOTTOM OF THE FILE And it's revealed that you're macros collide with your function names, and you're so proud of this messy cruft... Your "beautiful code" is a dumpster fire, mate. The description goes "Fair Warning: There is a fair bit of Programming religion in this talk." Yeah man, I love how many people are drawing the parallel with Terry Davis, because you are SO far down that path already.... Eskil, friend, heed the lessons of the past, man. Sheesh

Hahaha, main memory is 50 cycles. That has aged really badly, should be like 500-1000.

1:08:06 - Your pointer example is not valid because it is a void pointer. Even if you correct it, it will not be any faster than the index versions. Every compiler can optimize the plain version.

Isnt the array of bytes example at 1:47:00 technically buggy since the structure will get 3 byte padded at the end and these bytes will be used as part of the array? It still works but the mental model you are presenting is actually slightly incorrect. I think in your latest UB video you are also warning about that (Awesome video by the way - thank you!)

Wait, the LOVE guy?! Blast from the past, damn

Thank you so much for this excellent video!!! (from a cs50 noob) A video dedicated to architecture design would be amazing!

>fix it now, it won't be easier in the future No, it will be. If you're actively coding and learning newbie, tomorrow you'll understand it more, maybe your brain will even tip you some useful decisions after sleeping with it.

Great video, I learnt a lot. Do you have any recommendations on books or resources about the topics you cover in the video? Especially about the memory one.

So you’re telling me you declare your for loop variable outside of the for loop? That is probably the main thing that would bother me about using C89 lol

"people don't want to type" it's not that i don't want to type, i don't want to read. verbose code is more to read

"You want errors" Not surprised to hear that from someone who writes in C89. :p

I don't like "wide" code. But I like explicit. Public : A3F_SOME_FUNCTION A3T_SOME_TYPE A3D_SOME_DATA A3M_SOME_MACRO Private : ( on the honors system , basically not part of the public API , don't fuck with it unless you are fixing the library it belongs to. ) a3f_some_function a3t_some_type a3d_some_data a3m_some_macro

At 38:40, object orientation. Because code and data are stored in different memory segments you say computers really aren't object oriented. Yet you use functions with local variables. As an OOP fan, all I ask is that I be given an option to allocate variables from the heap rather than the stack. Isn't that the primary addition that objects provide? That particular argument against OOP is also an argument against local variables in functions.

coming back to this after getting my ass kicked by a few hobby projects in C 😂

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

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

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

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

First half is just "language X does Y which sounds really nice until Z" except you basically never experience Z and Y is absolutely amazing and makes you code faster

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

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

I would really love to see a whole C tutorial. I have been searching someone like you, who can really teach C. Please, I really insist you to make aa whole tutorial series for C. I am a new CS student. And I absolutely love C. I also want to do some networking, system programming. You tutorials will help me a lot and others too. Please make a series.

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.

"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.

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.

11:34 - C++ tries to hide things 55:30 - I've hidden my macro really well

1:47:10 "because I know what the hell I'm doing": no you don't! if you access data past the first element it's UB, that's what you're doing...

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.

Is your approach that because C++ has features that are easy to misuse you should just not use *any* of the features provided? the add() example would, for example, be an amazing candidate for templates, notice how that would be better, not worse. With regard to the multiplication example in C++, write better code! Someone writing ambiguous code is not a good argument for not using an entire language, it's an argument for better education. I don't think we should use C over C++ just because it has less features. C has it's place, but I don't think it's the same place as C++'s.

In your Javascript example - 'x' will not be ZERO, but 'undefined'.

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.

Started my journey of learning C++ 6 months ago from 0 experience in programming, just watched 16 minutes of your video for the moment but you're already saying "philosophical approach" stuffs I instantly felt during my very young journey. Very glad to hear my noob "feelings" are not that "heretic" : "why overloading if I could just type few more lines ? why hiding me some details of the code and optimize things I could do myself , getting me bad habits ?" ( especially when learning the roots of how everything work, it's hard to connect the dots lol ) Thanks from a rookie, to help me open my mind in this world :)

“if you’re gonna be a good programmer, you’re gonna want to learn how to do things” ugh exactly!!!!!! there’s so many phenomenal points in this presentation - Although there was a LOT of typos in it 😂 no judgement though

What what? You are saying that `realloc` causes page remapping using the MMU? Sorry but this seems incorrect. 1) Even if this is true, it should not be relied upon, it's not part of the C standard and is dangerous to even infer that one could rely on this. 2) glibc uses pools to allocate memory that is < 128kb in size. If the realloc size exceeds the size of the pool the memory was allocated from, it will allocate a brand new pointer and perform a memcpy 3) For allocations that are >= 128kb glibc will use `mmap` to create an anonymous mapping as this can be released back to the OS unlike memory obtained via sbrk. If you realloc to a size that exceeds the size of the `mmap` this will allocate a brand new pointer and perform a memcpy. 4) Getting the kernel to adjust the memory mappings via the MMU would be expensive both due to additional syscalls, and it would not be worth doing unless it hit 2 or more pages. 5) `realloc` is implemented in user space as part of libc, and has no notion of or even view of how memory is mapped by the kernel. This is why implementing buffer objects that never "realloc" but rather just allocate another buffer and provide an interface to read/write contiguous memory in the buffers is usually done. Or implementing memory pools for specific fixed size structs that grow by again, allocating additional buffers. Also your realloc example at 1:38:11 doesn't allow for the fact that `realloc` may fail, which if it does not only will you crash because `array` will become `NULL`, but even if you check for failure here, you will have leaked memory because you just overwrote your pointer with NULL and now you can't free it. As for your "faster" backwards remove, it depends on the size of each array element, you're literally copying around memory to do this. If you must do this, it is much faster to do a forward search (which is a far faster memory access pattern) for the index of the element you wish to remove, and then use `memmove` as it will take advantage of intrinsic operations to accelerate the copy. If the linked list struct is large, or your linked list is a huge data set, it's enormously faster to remove from a linked list as you only have to update a couple of pointers. You can also maintain cache coherency to a large extent with a linked list if you allocate your items from a memory pool (but that's subject to fragmentation depending on your usage patterns). Iterating backwards through the array can also cause cache latency issues because CPUs (especially older generation ones) expect to read ahead to fill the cache line, not read backwards.

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!

There is a bug at 1:50, not enough memory is allocated

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

I think C++ has become the opposite of C, at least when it comes to syntax. It is absolutely bloated with features, many of which exist solely to write 5 less lines of code. Goes against the simplicity, elegance and "what you read is what you get" syntax of C.

i would be interested to hear your opinions on Rust, as i think it makes a good effort to mitigate and even solve many of the problems you reference in non-c languages, while providing the cushy high-level interface many love.

This is insanely useful. Lots of idioms that a JS dev getting into C needs to hear.

There is some sexy code. I suppose the guide really reveals the philosophy of c. That’s so satisfying