Thank you for an amazing presentation, Nathan. Very informative.

Fantastic material and presentation! I really enjoy and appreciate seeing such a relatively clean implementation of OOP techniques in C!

Good job. A slightly different way than I use now. It is good to see different ways of implementing OOP. I think yours looks more like cpp. I tend to use build time memory allocation is set and immutable. It is nice to have another tool in the toolkit.
FYI: Would be nice if it was not just coming in on left speaker. (right channel had no sound).

Fantastic video Nathan!
I loved the idea of the nesting doll structures and magic numbers!

Hey, folks! I wanted to point out that I also answered a few questions that come up in the Live Q&A on the discussion thread associated with that video.

Two great questions were asked in the Q&A today for which I wanted to give a more thorough answer. Here they are:

1. Q: "How am I able to unit test a module if it's been abstracted (i.e. the internals are kept secret)?"
   There are two answers to this question, that I can tell: (1) "Don't" and (2) "Add some code that exposes the internals to a testing interface, but not to the rest of the application". (Elsewhere on the internet, Miro Samek seems to offer a third: "Use software tracing". He explained this technique in an earlier EOC talk, though I haven't watched it yet, myself.) The first answer, "Don't" means that if something has been hidden from the application, then the whole point is that we don't care about the implementation, just that the module adheres to the interface we've established in the header file. On the Embedded Artistry forum, Phillip Johnston also makes the great point that if you feel that you truly must test the internals of a module, then it's possible that your module has too many responsibilities and your design would be better served by dividing that module up, such that you can actually test, through a public interface, the things you want to verify. The second option, exposing parts of the module to strictly allow for unit testing, can be accomplished in a few ways:
   a. Use #ifdef...#endif to include/exclude the functions you need to test your module at build-time; the testing code includes something like #define TESTING while production code doesn't.
   b. Make WEAK functions that expose the internals of a module and then only provide implementations to the linker when compiling the testing code.
   c. Create derived classes for "production" and "testing". The "testing" derived class adds interface functions that expose the internals of the module.
   Although it's not clear to me if James Grenning explicitly answers this question in his book, "TDD in Embedded C", it seems to me that he employs both techniques throughout the book (in particular, the idea of creating a derived class that exposes certain details seems to be described in Section 11.5).

2. Q: "When should I just use C++?"
   To (frustratingly) quote many engineers, "It depends." If a project requires C, then it's a bit of a moot point; ditto if a project requires certain language features that are only available in C++ such as templates, constexpr, or the auto keyword. If it's just preferred that a project use C, then there are design trade-offs to be made.
   a. The biggest consideration might just be how well folks understand C++ vs "OOP in C" ("folks" should include not just you, but also anybody else who will be writing, reviewing, using, and/or maintaining your code). Once you've implemented OOP in C a few times, things make more sense (maybe even more sense then what the C++ compiler is doing to implement a "non-virtual default destructor"!) and it's easier to stick with "OOP in C" for larger and more complex projects.
   b. Another consideration might be the overall size of the project. It takes a little more code to write "OOP in C" as opposed to implementing the same modules/classes in C++ since, essentially, we're having to create our own virtual tables. Accumulated over a very large project it's possible that writing all of that extra code takes too long for your liking.
   c. However, that little bit of extra code is sometimes a good thing! By implementing OOP yourself, you actually have very fine control over exactly how those OOP features are implemented. Constructors in C++ can't throw exceptions, for instance, but with OOP in C, you can employ any error handling technique you want in your constructors, even an approximation of try-except! (CException from Throw the Switch is one such implementation and there are many others.) Relatedly, I don't think C++ is needed to implement any of the classic Design Patterns or any complex software architectures that one might build using a traditional OOP language; OOP in C is perfectly capable of those things.
   d. Lastly, if inheritance is needed, I think C++ is definitely called for, unless you're willing to forego the idea of modules being opaque, which eliminates one very big problem. Creating inheritance in C (safely) while maintaining abstraction, though, is exceedingly difficult.
   In summary, I think "OOP in C" is as or more capable than C++ in implementing OOP designs (inheritance notwithstanding). It's a great fit if you want to stay in C or want a fine control over how OOP is implemented in your project and don't mind writing a little extra code for each of your modules. After you've played around with the techniques and feel like you understand them, then I think you'll find that OOP in C can solve many or all of your design problems. On the other hand, you'd probably want to use C++ if you need inheritance or other C++ language features or if you aren't yet comfortable using the OOP in C techniques.

Very well done. I love the accelerated videos to get to what you are looking for :-)
In the encapsulation example, instead of iterating through the array to find 'unused' objects, I would have used a linked list of 'free' objects and then finding a free object is just the one at the head of the list.
I just question who encourages OOP using C?
Why not just use C++?