Q&A 22:11 Are you using a standing desk? 51:38 Should one use the C Standard Library? 1:00:01 Can you use regex extraction instead? 1:10:06 Could you use a printf() trick instead? 1:18:56 Can you recommend some good programming books? 1:19:52 Why do you not cache stb_arr_len() when you're looping? 1:22:13 What other advice would you give yourself if you go back 25 years? 1:25:06 Have you used ImGUI? 1:25:44 If I wanted to have my own standard library, would you think that would be better than trying to have one standard library for everyone? 1:27:46 Do you routinely use polymorphism with void* and function pointers in your C programs? 1:29:42 Is stb_arr_len() safe? 1:34:42 Can you create a debug GL context in SDL2? 1:34:59 Is it slow to open the debug GL context through SDL2? 1:35:20 What are the more simple STB libraries for beginners to start playing with? 1:35:50 Don't you think it's a good idea to rewrite the tools incorporating new knowledge to make the most impact? 1:39:40 Do you think with enough STB-like libraries out there eventually that C would be more competitive with higher-level languages in the future? 1:42:46 Are you using MS Visual C++6 for your IDE? 1:43:02 Is it wise to play with STB by looking at the library code? 1:45:02 Would you consider a specific pull request? 1:45:15 [wrap up]
@@roymarshall_ I don't get it either. You can write C++ in a very C-like way but with the added convenience of namespaces, function overloading, operator overloading, default arguments, and templates to replace macros. Most people who dislike C++ were forced to do the whole polymorphism + exceptions + RAII thing and think that's the only way to write C++.
This is one of the good ones. The algorithm takes me back here at least once every 6 months. Even though it's at least the sixth time, im watching again
Seeing him programming like this, making mistakes and so on, it makes me feel a lot better as a programmer. They all go through that, it's not just me.
I remember hearing in a talk, I think by Joe Armstrong of Erlang fame, the speaker say something like the following > when I used to live code in the classroom, my students would remark "it's so relieving seeing you [the professor] make all the same mistakes as us; the only difference is that you spot and fix them faster thanks to experience". It made me feel less sucky when I heard it :-)
@@jonaskoelker you people are pussies I swear to god. I bet you feel all warm and mushy when someone tells you that you're not supposed to constantly be sh*tting out perfect code.
The same applies to mathematicians and mathematics. I remember being told (i person, up the front after a lecture) that maths is actually messy and full of false trails; the texts never show the failed workings, or mention alternative formulations (due to space and (author + reader) attention constraints among other things).
It's the current year, and I literally have a supercomputer. It's watercooled and spinup sounds like an aircraft carrier. Yet, compiling takes longer than vs6.
Thanks a lot for this interesting video. Since the early 2017, I have switched to C for writing all my works and I am so happy about this decision I made. After 1 year, I wrote many C codes that are fast, easy to debug and very portable. I will never regret switching to C from all the interpreted languages or even C++.
@@lucasjames8281 C can be written for memory constrained devices or take better advantage of powerful hardware when datasets are large, which is sometimes a dealbreaker if the equivilent code in a memory managed language would be prohibitively slow.
@C D I don't know. Maybe he's busy. Maybe he's answering other questions. Maybe he doesn't want to answer the question. But he does appear to be alive so let's not spread rumors.
Thank you! I learned quite a bit, especially about some of the meta-data behind programming at a lower level. One thing - the reason for doing this (making a video) is, at least for me, for those that always wanted to program, loved computers, were plenty into it, but didn't necessarily have the resources (friends, relatives, teachers, etc) to learn from in order to advance their knowledge. So what you're doing is awesome for those types (like myself..) :) Thank you! :D
I immediately had to try making my own dynamic arrays! I got it working although I'm not sure how similar it is to your implementation.. I definitely would like it to be more elegant though, currently you can't pass rvalues to my push function D: 😂 Anyway great talk! thank you for that! and all your amazing contributions to the community!
The dynamic between what's good for small programs, through demos, betas and production is really interesting. Certainly agree that the only thing stopping people from using C more is the lack of public ecosystem (and the bad and outdated standard library). I think C is an incredibly powerful language in most of the regards people need.
I think you should be able to use memcpy/memmove to work around strict aliasing issues for the stb array code. That is, you'd have to memcpy (from type* or void*) onto a temporary stb__arr struct in order to do reads, and the reverse to do writes. Hopefully that makes sense. It is/would be ugly, but could be worth keeping in mind if you ever need to get the stb array stuff working in the face of strict aliasing optimizations. Totally agree that strict aliasing is annoying though. Ideally compilers wouldn't do that, except when asked to e.g. with `restrict`...
Faster to write 10 lines on php, than to load IDE; If you have a big project on c ++, like a game, then programming turns into a continuous compilation. Debugging game logic in c / cpp is awesome. You have to attach scripting languages, and even so that it does not lag. I lead to the fact that there is a tool for everything, and the programmer must be able to choose it correctly. This is a key point.
Interesting video, but I have an honest question. Much of your libraries are to a degree, reinventing what is already done in c++'s standard library. For example, your dynamic array implementation very much mirrors to implementation of std::vector. Both store 3 pieces of information (size, capacity, the base ptr itself). Both have appending to with "push" and will resize if needed. both offer array style indexing. It's pretty cool that you were able to do this in c, the idea of packing meta-data in a struct before the base address is something that I'm familiar with from allocators, but using it in this context is very clever, I'll probably use that trick more often myself :-). Well, I haven't actually asked a question yet, so here it goes. Why not use a limited subset of c++ to maximize code reuse? Are there any specific benefits to your implementation over the similar std::vector? The reason why I ask is that as you state, the c stdlib is very limited, but the c++ one is quite a bit larger. At the same time, there is nothing wrong with writing very c-style code with a c++ compiler. Why not have the best of both worlds? Anyway, just curious because I found some of this interesting.
@Tom Cheng, I suppose that this is something that we'll just disagree on. The way I see it, the vast majority of C++ is quite straight forward, and doesn't require esoteric knowledge to work with. Sure, there are some parts that feel like they are WAY too complex, but the reality is that things like SFINAE are largely a tool for library writers, not everyday coders. In my opinion, it's quite easy to stick to a subset which any competent C++ developer would be able to work with. For example, if you wrote code that was basically plain old C, but instead of manually managing strings, you just used std::string, do you really feel that anyone is going to have a hard time following or maintaining that? OK, how about if we add usage of a std::sort? Sure, at some point, you're bound to include some feature that not everyone understands, but I think that those are pretty easy to identify and avoid if feel the need. Don't like templates? don't use them! Don't like exceptions? same deal.
It's not that some people don't understand std::string, it's just that using a subset of C++ on a project requiries much greater management to make sure that everybody's using the same subset. I can choose not to use exceptions for example, but if anybody else on the project is using them, I'm totally fucked and I'll be leaking memory everywhere because I haven't wrapped all my resources in objects (RAII) If something goes wrong in a C++ codebase, it could be 1000 things. In a C codebase, only 100. Lil side note, check out Rust! This is the best 'best-of-both-worlds' solution I've seen so far, and seems to keep up / beat c/c++ performance wise
I really want to see what a great compiler for Rust would look like. It could do some crazy stuff with ownership, the kind of stuff that compiler-writers nowadays can only do based on undefined behavior (at the expense of many programmers sanity). I bet a really good Rust compiler could produce faster programs than C code.
I think the current limitations are in the LLVM backend, some of the stuff the rust compiler can do semantically just don't translate well? That being said, rust is already faster than C code in a lot of places. Take a look at 'ripgrep', a rust implementation of grep which I believe is faster than the original. The main benefit is that rust code is so robust, that at a certain project scale you can reach speeds you never could do safely with C. Writing fast C code in a huge project is very hard, unless the only people to have worked on it to date followed really strict procedures. Writing a big project like that in rust, the compiler enforces the procedures onto you - I think this is probably the main argument for rust being faster than C. It's just like how assembly is probably faster than C, but realistically it's too hard to write a whole project in assembly b/c it gets too hard to write past a certain scale.
So I don’t really need to learn c++ or even modern c++ due to the foot holes and mines that one usually avoids in the language while you will still find yourself rolling out your own . And in C there’s cosmopolitan the Hvm and Ryan fleury the c99/c17 is the way it seems from reading and looking at code from developers
20:48 I recently wrote some utilities, not necessarily "small" programs, writing them took a some hours and I had to fix some bugs in the following days in Rust. It's not C, but also not a scripting language like bash, python, perl, etc., and I think, it was a good idea.
@@MamaMia84oo7 I wrote 80 lines of codes to achieve that, without looking to any tutorial online, I saw just the beginning of a youtube video where the guy who made the video spoke about using the function system("cls") to clear the screen.
@@ryan-kys No bro, what are u talking about ? I don't do illegal activities, I just used the C library system() function with "cls" as an argument, also how would u manipulate the console buffer ? it's physically not possible ?
@@justcurious1940 sorry, i must've misunderstood something. you don't necessarily have to clear your console window, you can just use ncurses or send escape codes to your terminal for it to move the cursor
How can you know what parts of code you will reuse until you have 20 years of experience? You can end up implementing code that you'll never use ever again.
You dont need 20 years, you just have to identify what you do a lot and make it reusable. It does take time, but NOT 20 years. Sure after 20 years you should already know, but you would also have written a lot of it
@@johnjackson9767 What types of data struct is used with C? Because in OOP languages is common use virtual functions to just write a for loop and update all in the game.
Totally respect your skill, and knowledge, so don't take this the wrong way. I think people that blithely shrug off newer tools without looking into them to be making a rather silly mistake. Never willfully ignore something that could save you a lot of time in the long run. I can't find much virtue in using a single language for all of your utilities, either. What you demo in the video (finding stb_ tokens) could be done in 30s with a tiny bit of Perl knowledge that it would not take long for someone intelligent such as yourself to learn.
naikrovek He seemed to pretty clearly suggest taking that approach for the viewer and that his approach works for the specific niche he's carved in his own life. That doesn't take away from your point, but your point *is* reiterating what was mentioned in the video.
Please do a video on the C abstract machine layer communication theory, x8086 PC AT assembly communication theory, and the translation between them as three independent discussions. That is what I am going to work towards. You could use sockets as a basic language parallel but the video should be independent of any library dependencies including sockets.h. The process and controlling expressions must be self contained to C/Assembly so that it's constraints are plain. For example, an inherent C design limitation is not being able to modify the symbol table from within the program at run time(I am still learning). The symbols must be found in the native character set of ASCII excluding the control characters(96), or the symbols(keywords such as 'if' or operator '=') in the Standard without the standard library('setjmp' as opposed to 'goto label' would require an Assembly explanation within the C discussion). Support for your explanation and preferences with direct citations to the the standard, say C99 or earlier for conservative compatibility, data sheets for the PC AT x8086 including the word sets(timing, resolution and sequences) or its standard, or real world experience to proffer new people like me. A fourth good topic would be the previous three topics as it concerns the controlling design limitations in the language and translations between such as symbol table and external linker. A fifth, BIOS interface.
Functions have an overhead on the CPU for calling them. Registers and the stack get used for passing parameters, then the CPU has to jump to a different memory address to read the function code, then it often has to restore the registers to the state they were and jump back, all of these take clock cycles. A #define just replaces the word in your program with the code before the file is even compiled, so none of those steps are necessary. In short, it’s just faster if you can do it that way.
In c its impossible in many cases to write code that is type independent which you oftentimes want (for example when working with vectors) so you can cleverly use macros that just take the name of your variable and do your operation in line like that. The performance cost is negligible and if it wasn't the compiler would probably in-line it for you (c has very good optimizers by now so you need not worry)
@@SeanTBarrett Thanks! This gives me nostalgic as I played with VC++ 6.0 many many years ago. Although I never went into programming officially that was still fond memory. BTW thank you for your videos and your games!
[7:20] Here is my C++14 Python-like version (produces the same result): #include "python" //Python: #!/usr/bin/python by_(anagram) = {}; //Python: by_anagram = {} auto names_file = open ("dist.male.first"); //Python: names_file = open ("dist.male.first") for_line (in names_file); //Python: for line in names_file: auto name = (line.split())[0]; //Python: name = (line.split())[0] auto letters = (letter_for_letter_in_name); //Python: letters = [letter for letter in name] letters.sort(); //Python: letters.sort() auto sorted_name = ""_join (letters); //Python: sorted_name = "".join (letters) if _not sorted_name in_by_anagram //Python: if not sorted_name in by_anagram: by_anagram[sorted_name] = {}; //Python: by_anagram[sorted_name] = [] by_anagram[sorted_name].append (name) //Python: by_anagram[sorted_name].append (name) for_(sorted_name, in by_anagram) //Python: for sorted_name in by_anagram: if (len (by_anagram[sorted_name]) < 2) //Python: if len (by_anagram[sorted_name]) < 2: continue; //Python: continue print (by_anagram[sorted_name]) //Python: print by_anagram[sorted_name]
@@rusi6219no developer is buying a computer with less than 16 GB of RAM, because they don't make computers with that little ram that have the type of processors we need.
It's quite funny how you advocate for writing small programs in C, but spend quite a bit of time debugging trivial code. With Python stuff just works. Easy install and usage, unicode by default, a traceback on errors, ALL unhandled errors are caught, a plethora of libraries with a sane API, string formatting. Sure, there are still moments when you'll make a mistake or will have to figure out some gotcha, but those are so much easier to catch in Python. When I need to automate something for personal use, I don't even think whether I should do it, I just do it, because it's just a few minutes. I'm all for C for serious programming, but when it comes to writing scripts/small programs there's pretty much no reason to avoid the obviously right tool for the job. The only time I would use C for a small program is when Python is not fast enough (be it single or repeated use) (which is so obvious, I don't know why I feel the need to explain it) It just feels like you don't have any objective reason to always use C. I get that it's just intended as advice to those who are inclined to use C. But this still feels like an old man's attitude.
8:10, using C++, I achieved this in 30 lines, with no extra file else than its own standard lib., STL. 9:34, in C++, you can just write a lambda f(), which is a f() inside that quick sort. No wonder why I leaved C. 10:55, writing games in C is kind of a suicide to me. 11:38, C++ is the best for games and anything else.
"10:55, writing games in C is kind of a suicide to me" - well that's the difference between a bedroom script kiddy and a GENIUS like Eskil Steenberg!!!
@@trefwoordpunk2225 Dude, I was successfully fighting against global/public variables (C-style) while you still was pooping and rubbing your feces in your face. If he managed to tame the beast, he may indeed be a genius. However, for instance, he said he is always afraid to access an array in the cache - and his method to prevent errors in the heap is clunky as hell. This is for me a long time gone issue: I access any kind of array safely, without adding any line of code, leaving the entire work automatically for my lib. in C++.
ironic how the guy who talks about how C is a good way of writing small programs runs into 4-5 segfaults and bugs in a simple program (literally counting words in a file). use split string into vector of words, find_if starting with "stb" and get on with your life. it will be faster to implement, faster to execute and less buggy.
Yeah, it’s slow af and takes a browser engine to run it... also, it has no types whatsoever so a typo is a new member in your object. U can use typescript but it’s compiler is slow af cuz it’s written in JavaScript.