This video took A LOT of time to make. Just the script I had to rewrite like 3 times. So, if you like what you see, please share this video with your C++ inclined friends if you found this video useful. 🙏 And do leave a comment, this way this video will be shown to more people apparently 🤷😉
Дякую! Радий, що сподобалось! Подивимось, взагалі план був про це розказати, але це така велика тема і в ній так багато чого відбувається, що я не впевнений що зможу її просто і добре пояснити. Але вона у мене в планах. 👍
@@McDonaldIbekwe ok, so there is one video on testing that I did before but it is not in-depth. As for coroutines I would have to use them in some real projects to be able to speak confidently about best practices that relate to them unfortunately. 🤷♂️ I will try to squeeze some multithreading in though at some point but I can’t say when just now 🤷♂️
Very Nice lecture, all my years I have always been a Composition over Inheritance supporter as well I knew that private inheritance can get the job done but never bothered to see how; example at 9:59 cleared the syntax and semantics up perfectly. ☺
Nice and clean overview. However, dynamic polymorphism is a very well known and old topic in C++. I would suggest deepening into static polymorphism for the next video. Keep it up, it is refreshing to see technical C++ stuff in TH-cam 2024
@@SystemSigma_ thanks! I actually put static polymorphism before this video, it’s right along a series of videos about templates: th-cam.com/video/1Mrt1NM3KnI/w-d-xo.html Still not the most modern thing but necessary to understand concepts down the line I believe. I also wanted to give an overview eventually of how to do the same things using both dynamic and static polymorphism on some concrete examples. But for that people need to be familiar with both. Does this make any sense?
@@CodeForYourself It does indeed. I meant that modern c++ features (especially type traits) are really useful for making more robust static polymorphic code. Maybe instead of going too generic with topics, restricting the features scope may be more interesting for experienced viewers.
@@SystemSigma_ I agree that a more in-depth look would suit experienced folk better. My aim here, however, is to fill in the complete playlist that would tailor to somebody who knows nothing about C++ and guides them gently through all the main topics, providing the "why" for using what they learn along with enough information to dig deeper. Please see here for the full list to date: github.com/cpp-for-yourself/lectures-and-homeworks Maybe one day, I will finish the basic course and have some time to dig more in-depth into certain things. That being said, I feel that there is plenty of that type of content on TH-cam already, while the comprehensive courses that I've seen all fell a bit short of what I wanted to achieve here. But we'll see if my course is going to be helpful to anybody 😅
@@SystemSigma_ oh, and just in case you have not seen already, I _do_ talk about type traits a bit more in-depth here: th-cam.com/video/IQ62tA51Vag/w-d-xo.html
SPOILER: Wrapping everything up with the Image class example from the start was a very nice move 👍 I really enjoyed this lecture and will definitely recommend this further. Thanks a lot for your awesome content! 👏
Thanks! I’m really happy that that move clicked. It was a long video so I wanted to end at one consistent example that would be relatively close to real life. 🙏
That is it make sure that when we call these functions we look up the actual functions to be called in the vtable. In the end of the example we pass a reference to an *IoInterface* object. So try to make sure you understand exactly what will happen when we call *Write* on such an object reference. Does this help?
@@CodeForYourself I understand what you mean but in the video you used "void Write(const std::filesystem::path& path, const std::vector& data) const override { std::cout
@@erkamkocaer2097 oh! Now I understand! Thanks for pointing it out! It's a bug I have on GitHub. We *can* have *virtual* and *override* for the same functions but generally we should just use *override* as the *virtual* is implied here. So basically what I'm trying to say is that *override* implies *virtual*. I'll remove *virtual* from my GitHub code as it was probably a copy-paste error on my side. Thanks again!
Yeah, I thought of fitting to the standard UML style but then left it at that considering that the tools I used for creating the visuals did not have a non-filled arrow 😅
Yes, you are totally right, but I much prefer to be explicit rather than implicit. My logic is that it is not a big deal to type one more word but it allows us to not think about which inheritance is going to be picked by the compiler implicitly should we omit that “public”. Does this logic make sense?
This video took A LOT of time to make. Just the script I had to rewrite like 3 times. So, if you like what you see, please share this video with your C++ inclined friends if you found this video useful. 🙏
And do leave a comment, this way this video will be shown to more people apparently 🤷😉
Чудова лекція. В майбутньому було б цікаво почути щось на тему concurrency, threads загалом.
Дякую! Радий, що сподобалось! Подивимось, взагалі план був про це розказати, але це така велика тема і в ній так багато чого відбувається, що я не впевнений що зможу її просто і добре пояснити. Але вона у мене в планах. 👍
I like your (semantic) separation of impl.. inheritance and polymorphic inheritance 🎉
@@bsdooby thanks! I think it makes sense to teach them as separate concepts altogether
Haven't watched this yet, but I know it is good! One of the best C++ creators out there for sure!
Thanks for your support and such a trust in me 🙏 But feel free to revise once watched 😉
true words
Thanks for the video.
Please, can you focus more on Modern C++. Here are some:
1. Coroutine
2. Multithreading/Concurrency
3. Testing
@@McDonaldIbekwe ok, so there is one video on testing that I did before but it is not in-depth. As for coroutines I would have to use them in some real projects to be able to speak confidently about best practices that relate to them unfortunately. 🤷♂️
I will try to squeeze some multithreading in though at some point but I can’t say when just now 🤷♂️
Very Nice lecture, all my years I have always been a Composition over Inheritance supporter as well I knew that private inheritance can get the job done but never bothered to see how; example at 9:59 cleared the syntax and semantics up perfectly. ☺
Glad it was helpful! 🙏
Nice and clean overview. However, dynamic polymorphism is a very well known and old topic in C++. I would suggest deepening into static polymorphism for the next video. Keep it up, it is refreshing to see technical C++ stuff in TH-cam 2024
@@SystemSigma_ thanks! I actually put static polymorphism before this video, it’s right along a series of videos about templates:
th-cam.com/video/1Mrt1NM3KnI/w-d-xo.html
Still not the most modern thing but necessary to understand concepts down the line I believe.
I also wanted to give an overview eventually of how to do the same things using both dynamic and static polymorphism on some concrete examples. But for that people need to be familiar with both.
Does this make any sense?
@@CodeForYourself It does indeed. I meant that modern c++ features (especially type traits) are really useful for making more robust static polymorphic code. Maybe instead of going too generic with topics, restricting the features scope may be more interesting for experienced viewers.
@@SystemSigma_ I agree that a more in-depth look would suit experienced folk better.
My aim here, however, is to fill in the complete playlist that would tailor to somebody who knows nothing about C++ and guides them gently through all the main topics, providing the "why" for using what they learn along with enough information to dig deeper. Please see here for the full list to date: github.com/cpp-for-yourself/lectures-and-homeworks
Maybe one day, I will finish the basic course and have some time to dig more in-depth into certain things. That being said, I feel that there is plenty of that type of content on TH-cam already, while the comprehensive courses that I've seen all fell a bit short of what I wanted to achieve here. But we'll see if my course is going to be helpful to anybody 😅
@@SystemSigma_ oh, and just in case you have not seen already, I _do_ talk about type traits a bit more in-depth here: th-cam.com/video/IQ62tA51Vag/w-d-xo.html
SPOILER: Wrapping everything up with the Image class example from the start was a very nice move 👍
I really enjoyed this lecture and will definitely recommend this further.
Thanks a lot for your awesome content! 👏
Thanks! I’m really happy that that move clicked. It was a long video so I wanted to end at one consistent example that would be relatively close to real life. 🙏
why did you use virtual on Write functions for jpegio and pngio at the final example code?
That is it make sure that when we call these functions we look up the actual functions to be called in the vtable. In the end of the example we pass a reference to an *IoInterface* object. So try to make sure you understand exactly what will happen when we call *Write* on such an object reference.
Does this help?
@@CodeForYourself I understand what you mean but in the video you used
"void Write(const std::filesystem::path& path,
const std::vector& data) const override {
std::cout
@@erkamkocaer2097 oh! Now I understand! Thanks for pointing it out! It's a bug I have on GitHub. We *can* have *virtual* and *override* for the same functions but generally we should just use *override* as the *virtual* is implied here. So basically what I'm trying to say is that *override* implies *virtual*. I'll remove *virtual* from my GitHub code as it was probably a copy-paste error on my side.
Thanks again!
@@erkamkocaer2097 I've updated the code on GitHub to not have *virtual* in the last example. Thanks again for bringing it up!
@@CodeForYourself thank you for your attention. I like your cpp videos. They are really impressive.
nitpicking: if you use UML for you examples, the impl. arrow (realization of an interface) has a non-filled arrow head.
Yeah, I thought of fitting to the standard UML style but then left it at that considering that the tools I used for creating the visuals did not have a non-filled arrow 😅
structs do not need "public" inheritance; structs are public by default (sorry for being a PITA); you spare a few keystrokes ;)
Yes, you are totally right, but I much prefer to be explicit rather than implicit. My logic is that it is not a big deal to type one more word but it allows us to not think about which inheritance is going to be picked by the compiler implicitly should we omit that “public”. Does this logic make sense?