Thanks Gary for making this video even though it might not be your most viewed video - really interesting and informative! On the off change this might get pretty redundant now, I would wish for a golang version
Yes! Gary you are a very naughty naughty boy, or you are ignorant. Actually I believe the single initial underscore is reserved for any implementer of a standard library, while the double __ anywhere in a symbol is reserved for the standard itself and the compiler implementer. Symbols starting with _E are also reserved (errno.h?), and POSIX also reserves a lot of other (macro) prefixes, except it isn't required to comply with POSIX in order to comply with the C standard.
Technically according to ISO9899 section 7.1.3 is it, "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." Naughty me! But then again, anything after the C Programming Language (2nd Edition) is apostasy! 😜
@@GaryExplains Should make more C tutorial videos. That pointers video was good. I think they would be popular and useful videos. Today was surprised by how few C programming tutorials are in that channel. C and assembly are core for software engineering, and seem to be capable of making good tutorials on those. Thanks in advance👍🏻
There is a really nice programming language called Nim that I'd think you'd like. It has a similar look to Python but with type annotations, but it compiles to C so it is in the ballpark of C performance-wise. The reason I think you'd like it is because it is better fitted for tutorials like this because it is easier to read, especially for people not very experienced in C. It's also safer as it has good abstractions over pointers and such. It does for example pass function arguments by reference if the type is larger than 24 bytes but the compiler won't let you modify it unless you explicitly mark the argument as mutable.
@@VivekYadav-ds8oz Not necessarily, if you're not very good at low-level programming and is used to high-level languages like Python then I think that reading Nim is significantly easier to read than C. But sure, if you already know C it will of course be easier to read than Nim. But that would hold true for any language you don't know :) Regarding getting help, Nim has quite an active community with a forum and a bridged Discord/IRC/Matrix/Gitter server. But I'll admit that it is sparse on some tutorials, that's why it would be great if someone as educative as Gary did some tutorials on it ;)
Thanks - great video on finite state machines! anyone else’s eyes catch the inconsistent formatting around 3:36 with the missing space if found != NULL
@@GaryExplains I've used switch/case statements many times and in many languages to implement a FSM. They've all worked perfectly. Your statement is infinitely wrong and bizarre, and shows some finite state thinking.
@@maxwellsmart3156 Switch case is great for a few states. But it is a nightmare when you have many states. Hard to read and terrible to maintain. I suggest you reconsider your thinking.
@@GaryExplains You're the one who says a Switch/Case is "completely wrong". I made no representation that it was the only implementation for an FSM. Now you're making up "reasons" Any code can be hard to read and terrible to maintain. Code that is visual like a switch or a data driven approach using a CSV files are easy for those coming after you. I just didn't think you were going to be so rude about my original observation because it was a valid point. And I didn't know you were going to trip over your ego.
Bad styled C, please update methods from old old style C to a bit newer C. But honnestly C is a "dead" language. C++ is alive, I would recommand using C++, even for the same code... (C++ is not an object oriented language, so no I don't say : make it in objects...) For good pratice, try to const all vars and create them with the smallest scope possible, and only declare and init them at the same time. These points makes a world of difference for re-reading the code, and in perf.
Test things out with godbolt and read stuff out, like I don't know, cppcoreguideline. You see that it's not just my opinion... Or run cppcheck, and/or clang-tidy. Doesn't mention "can be const" but do mentions lots of things.
Except for the fact that I say that C is a dead language... No real update since C11... And there is nothing C can do that C++ can't do at least as well. But it often can do it better/cleaner.
Once you start talking about "style" then it is opinion. Most projects and companies have their own "style" and corresponding style guides. As for C is dead, hmmm, according to the TIOBE Index for May 2021, C is still king and C++ is less popular than Python and Java.
@@VictorMistral I am happily writing C code on microcontrollers, even though C++ is generally available and supported. It just doesn't have any advantages over C if you are doing real-time, bare metal stuff. If anything some of it gets in the way (like its constant nagging about harmless design choices).
Pointers for a state machine? You got to be kidding, man... that's some of the worst advice I have ever seen. The very point of state machines is that they are an ABSOLUTELY SAFE programming paradigm. Inserting a pointer makes this a nightmare to debug.
Interesting comment. Which particular use of pointers are you objecting to? I made this video two years ago, so just went back and looked at the code and there doesn't seem to be any problematic use of pointers. I use a point to the current state, that is about all. Nothing complex or difficult. Standard C really.
@@GaryExplains I am using C all the time, too. I rarely use pointers and I never use pointers for important stuff like program state. I do, of course, have an industrial product out there that has been running for the last 20 years with 100% uptime and zero known bugs. I guess I am doing it wrong, then. I should have used pointers to get frequent bug reports. ;-)
What worries me is that you think that somehow the code that the compiler emits is somehow better or safer with . rather than -> if you think that, then I can't help you.
I think you're right, but I also think for the sake of teaching, C is a great language. A lot of people know it, and there something beautiful (I think) about how simple the language syntax is, yet we can do soo much with it. Cheers!
"No one should code in C nowadays." But tens of thousands of people do. I expect to this day C is likely to be still the most in-use language for systems-level and other low-level programming. If we were going to have an argument over language choice for state machine construction I'd place TLA+ as my #1 choice or Verilog/VHDL as joint second. Third would probably be SystemC.
Thanks Gary for making this video even though it might not be your most viewed video - really interesting and informative!
On the off change this might get pretty redundant now, I would wish for a golang version
Using Two underscrores __ at the beginning is reserved for the Library/Compiler, also _t at the end might be reserved for POSIX headers.
Yes! Gary you are a very naughty naughty boy, or you are ignorant. Actually I believe the single initial underscore is reserved for any implementer of a standard library, while the double __ anywhere in a symbol is reserved for the standard itself and the compiler implementer. Symbols starting with _E are also reserved (errno.h?), and POSIX also reserves a lot of other (macro) prefixes, except it isn't required to comply with POSIX in order to comply with the C standard.
Technically according to ISO9899 section 7.1.3 is it, "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." Naughty me! But then again, anything after the C Programming Language (2nd Edition) is apostasy! 😜
@@GaryExplains Should make more C tutorial videos. That pointers video was good. I think they would be popular and useful videos. Today was surprised by how few C programming tutorials are in that channel. C and assembly are core for software engineering, and seem to be capable of making good tutorials on those. Thanks in advance👍🏻
Glad to see the C version of that FSM. Thanks Gary.
There is a really nice programming language called Nim that I'd think you'd like. It has a similar look to Python but with type annotations, but it compiles to C so it is in the ballpark of C performance-wise. The reason I think you'd like it is because it is better fitted for tutorials like this because it is easier to read, especially for people not very experienced in C. It's also safer as it has good abstractions over pointers and such. It does for example pass function arguments by reference if the type is larger than 24 bytes but the compiler won't let you modify it unless you explicitly mark the argument as mutable.
But since it's obscure, it would be hard to follow along and get help regarding the language-related problems that might arise.
@@VivekYadav-ds8oz Not necessarily, if you're not very good at low-level programming and is used to high-level languages like Python then I think that reading Nim is significantly easier to read than C. But sure, if you already know C it will of course be easier to read than Nim. But that would hold true for any language you don't know :)
Regarding getting help, Nim has quite an active community with a forum and a bridged Discord/IRC/Matrix/Gitter server. But I'll admit that it is sparse on some tutorials, that's why it would be great if someone as educative as Gary did some tutorials on it ;)
*GARY!!!*
Good evening Professor!
Good Evening fellow classmates!*
Stay safe out there everyone!
MARK!
Thanks - great video on finite state machines! anyone else’s eyes catch the inconsistent formatting around 3:36 with the missing space if found != NULL
Inconsistent formatting... LOL... I guess at least it means you were paying attention.
Love your videos on programming 😍😍
Nice, interesting.
THANK YOU
Using a case statement would be easier for beginners to understand and debug.
Yes, maybe, but it is completely the wrong way to implement a FSM.
@@GaryExplains I've used switch/case statements many times and in many languages to implement a FSM. They've all worked perfectly. Your statement is infinitely wrong and bizarre, and shows some finite state thinking.
@@maxwellsmart3156 Switch case is great for a few states. But it is a nightmare when you have many states. Hard to read and terrible to maintain. I suggest you reconsider your thinking.
@@GaryExplains You're the one who says a Switch/Case is "completely wrong". I made no representation that it was the only implementation for an FSM. Now you're making up "reasons" Any code can be hard to read and terrible to maintain. Code that is visual like a switch or a data driven approach using a CSV files are easy for those coming after you.
I just didn't think you were going to be so rude about my original observation because it was a valid point. And I didn't know you were going to trip over your ego.
@@maxwellsmart3156 OK. Then let's stop here.
Now you should give an example using the State pattern en.wikipedia.org/wiki/State_pattern
aight
Bad styled C, please update methods from old old style C to a bit newer C. But honnestly C is a "dead" language. C++ is alive, I would recommand using C++, even for the same code... (C++ is not an object oriented language, so no I don't say : make it in objects...)
For good pratice, try to const all vars and create them with the smallest scope possible, and only declare and init them at the same time. These points makes a world of difference for re-reading the code, and in perf.
In your ever so humble opinion.
Test things out with godbolt and read stuff out, like I don't know, cppcoreguideline. You see that it's not just my opinion... Or run cppcheck, and/or clang-tidy. Doesn't mention "can be const" but do mentions lots of things.
Except for the fact that I say that C is a dead language... No real update since C11... And there is nothing C can do that C++ can't do at least as well. But it often can do it better/cleaner.
Once you start talking about "style" then it is opinion. Most projects and companies have their own "style" and corresponding style guides. As for C is dead, hmmm, according to the TIOBE Index for May 2021, C is still king and C++ is less popular than Python and Java.
@@VictorMistral I am happily writing C code on microcontrollers, even though C++ is generally available and supported. It just doesn't have any advantages over C if you are doing real-time, bare metal stuff. If anything some of it gets in the way (like its constant nagging about harmless design choices).
woo
Start-brackets down on their own lines, never spaces after 'if', 'while', etc. But otherwise an excellent video ;-)
Start-brackets on the same line, always spaces after 'if', etc. But otherwise an excellent comment ;-)
First
doesnt matter if you're first lol
Pointers for a state machine? You got to be kidding, man... that's some of the worst advice I have ever seen. The very point of state machines is that they are an ABSOLUTELY SAFE programming paradigm. Inserting a pointer makes this a nightmare to debug.
Interesting comment. Which particular use of pointers are you objecting to? I made this video two years ago, so just went back and looked at the code and there doesn't seem to be any problematic use of pointers. I use a point to the current state, that is about all. Nothing complex or difficult. Standard C really.
@@GaryExplains I am using C all the time, too. I rarely use pointers and I never use pointers for important stuff like program state. I do, of course, have an industrial product out there that has been running for the last 20 years with 100% uptime and zero known bugs. I guess I am doing it wrong, then. I should have used pointers to get frequent bug reports. ;-)
🤦♂️ So x.y is safer than x->y thanks for letting me know.
@@GaryExplains If you don't understand the difference, then nobody can help you. ;-)
What worries me is that you think that somehow the code that the compiler emits is somehow better or safer with . rather than -> if you think that, then I can't help you.
Please do Rust, C is extremely dangerous and leads to multibillionaire vulnerabilities every day. No one should code in C nowadays.
I think you're right, but I also think for the sake of teaching, C is a great language. A lot of people know it, and there something beautiful (I think) about how simple the language syntax is, yet we can do soo much with it. Cheers!
"No one should code in C nowadays."
But tens of thousands of people do. I expect to this day C is likely to be still the most in-use language for systems-level and other low-level programming.
If we were going to have an argument over language choice for state machine construction I'd place TLA+ as my #1 choice or Verilog/VHDL as joint second. Third would probably be SystemC.