Дякую за хороші відгуки! Стосовно змінних, загалом всі змінні в cmake це просто текст. І більшість цього тексту зберігається в кеші який потрібен для того щоб зберігати конфігурацію між запусками. А все інше про за я розказую то наслідки цього.

@@CodeForYourself Да, только момент с кешем не уловил. Все остальное кристально. Особенно понравилась презентация на гитхабе. Я вот раньше просто смотрел, ничего не повторяя. Сейчас Вы сказали "не тупить" и выполнить все самостоятельно. Начал это практиковать. Времени намного больше занимает, но после ощущение будто сам все сделал. А если вопросы есть, гпт использую. Еще раз спасибо :-). Подписка, лайк

@ozimandias1858 будьте обережні з гпт, адже він хронічно бреше. Будь які конкретні запитання можна також задавати тут або на гітхабі. Я відповідаю повільніше за гпт, але сподіваюсь що менше брешу 😅

Thanks for the compliments! Whenever you see code animations I use motioncanvas.io The rest of the animations, including the last diagram animation here about shared pointers, I make by creating images with the Apple's Freeform, import them into Davinci Resolve where I edit my videos, and do the rest of the animations there.

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<Color>& data) const override { std::cout << "Writing PNG to path: " << path << std::endl; }" function but on github you used "virtual void Write(const std::filesystem::path& path, const std::vector<Color>& data) const override { std::cout << "Writing PNG to path: " << path << std::endl; }" function for both png and jpeg. I expected and understood first function but did not understand second one.

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

Thanks a lot! Happy to hear it was useful!

That is a valid question. The main reason is that some people prefer a video format and a video allows me to do both, have a markdown article and a video. You can find the markdown under the video. The downside is of course that errors are harder to fix.

@@richardbennett4365 Same explanation as for the first change. The blank T-shirt is the original recording and the “save the earth” one is the follow-up 😅

@@richardbennett4365 simple. I recorded everything and then, when editing found that the story wouldn’t add up. So had to re-record and add a part. But the old tshirt was already in the laundry basket 😅

@@segfault4568 yes, my experience exactly. That mess is exactly the reason for all the smart pointers 😬

@@leonardodosanjoschaves6204 awesome! Glad to hear it was useful and good luck!

@@leonardodosanjoschaves6204 happy to hear that! 🙏

Arena allocators definitely have their use! However, if we allocate a lot of objects we will quickly need to manage memory in complex ways. This lecture targets largely the default behavior for beginners. I believe that using the heap for allocations should be completely fine in most domains. Also, heap implementations benefit from years of optimization and as far as I know they basically use arena like allocations for small objects. That being said, if one really writes a safety critical application and cannot use heap memory at runtime then yeah, we’ll probably need to allocate stuff from an arena. Also, I don’t agree with putting garbage collection and smart pointers in the same row. They are very different mechanisms. Smart pointers are definitely reliable and in case of a unique pointer have nearly no overhead. So if one wants to allocate on a heap, smart pointers are definitely a way to go.

@@advik-b thanks for your kind words! Spread the word then. Let’s fix it. 😅

Glad you liked it! 🙏

Glad it was helpful! 🙏

Thanks! I’ll try my best 👌

@@SanjeevKumar-nm7ps thanks so much for your kind words! You make me blush! ☺️ Glad that it is useful to you! 🙏

Oh, that’s very easy. You just mess up in the script, spend a week editing, then see that it’s wrong and that you have to re-record parts. 😅

Not yet, but maybe some day once I finish a full course here.

Could you elaborate a bit on how unique_prt is obsolete? This is the first time I hear about it.

How is Unique pointer obsolete? it executes the same instructions as Raw pointer, same size as well, Scott Myers even recommended them to be used in tight cycles. Shared pointer though not to be confused with Auto GC is still a deterministic destructor so plenty useful, the only inefficient thing I can recall about Shared pointer is that it is twice the size because of control block pointer.

@@segfault4568 I have a similar view (thus my original question to the OP). As for the shared pointer the reference count is atomic if I remember correctly, which requires synchronization and therefore might cost additional resources and instructions.

Thanks! The font is Fira Code. The theme that you see in the animations is a custom one that more or less resembles the default vscode one.

@@CodeForYourself Thanks!

@@tirthasg sure, anytime!

Thanks so much! 🙏

Thank you so much! 😊

I’m not entirely sure which one I used back then but I have mostly converged on using Fira Code everywhere now.

@@bsdooby thanks! I think it makes sense to teach them as separate concepts altogether

Thanks a lot for the compliments! 😌

@@Pedro-jj7gp that’s just the way it usually is on most modern systems: any pointer is 8 bytes. In the end this has to do with being able to address enough places in the memory if this makes any sense. That being said, other systems could theoretically have it be smaller or larger. Does this answer your question?

@@CodeForYourself It does, but I'm a bit confused as I was watching some other videos about vtables and they showed the vpointer taking up 4 bytes... I guess it could just be on that system.

@@Pedro-jj7gp it might be. But you can always check it on your system too. I’ve only ever seen 8-byte pointers on every system apart from really non-standard embedded boards. 🤷‍♂️

@@CodeForYourself Yup, you're right! I just checked using sizeof() both for a regular int* and a vpointer using reinterpret_cast<int*>() and both are 8 bytes. The video in question was 12 years old, maybe it was a 32-bit machine

@@Pedro-jj7gp sounds like a 32 bit system indeed. Glad that it makes sense now 👌

@@SystemSigma_ thanks! I actually put static polymorphism before this video, it’s right along a series of videos about templates: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-1Mrt1NM3KnI.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 RU-vid 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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-IQ62tA51Vag.html

@@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 🤷‍♂️

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?

Дякую! Радий, що сподобалось! Подивимось, взагалі план був про це розказати, але це така велика тема і в ній так багато чого відбувається, що я не впевнений що зможу її просто і добре пояснити. Але вона у мене в планах. 👍

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 😅

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

Thanks for your support and such a trust in me 🙏 But feel free to revise once watched 😉

true words

@@GeorgiosMATZARAPIS thanks man 🙌

@@akshaypratap4123 that’s not how I think I am usually perceived at all. Especially when I’m coding. 😅

@@rishiniranjan1746 thanks! This means so much to me! 🙌

@@BISONBOT94 awesome! Glad I could help out! 🙏

@@UvUtkarsh generally the code is written in such a way that as long as the provided types follow some form of an interface they should work. They also use traits and partially specialize classes based on what those traits tell about the provided type. I might do an in-depth look into this later if there is interest

There is an example of this towards the end of the video. Does that answer your question? Or should I give a better example? How can I make it better?

@@isfandyar3937 also, I cover this extensively in this video: Why use templates in modern C++ ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-1Mrt1NM3KnI.html

Glad you liked it! 🙏

I guess you're right to a degree but there is more to it. Explicit template instantiation (different from specialization) does indeed help the compile times. It helps because without it, the code would live in header files and so would be copied to any translation unit that includes that header, leading to the compiler needing to compile all of those instances on their own. If we put the code into a source file (and for that we need an explicit template instantiation) we will only compile the code once and link it to the places where it is used instead. Does this make any sense? Now as to other benefits, one big downside of header-only libraries, apart from compilation times, is that all the implementation actually lives within the header files. Meaning that if we want to distribute our library to other people we essentially have to distribute source code. So in the end, we have a sort of a tradeoff, header-only libraries are quite simple to use but might lead to long compile times as well as to needing to show our source code to anybody using our library. I talk about this at length in the video about libraries here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Lxo8ftglwXE.htmlsi=JYNvd_2i6GLjfdvv

I'm perfectly aware of the standard benefits of splitting declaration and definition.. Still, for templates I really don't think it's worth the typing effort (if you're outside a smart ide) 😅 I guess the most valid point is only hiding the source code for distribution 😊

@SystemSigma_ sometimes the compile times are important too. Some years ago I added a couple of explicit instantiations in a code base to save about an hour compile time 😅 I think if we *know* the types we’re about to use, then I would go for a compiled library as opposed to a header only one. It works also as an additional check for my design to a degree 🤷‍♂️

@CodeForYourself yeah, I used it with quite a success in a few embedded projects, but, of course, every project is different so 🥲

@@SystemSigma_ yeah, I agree. 🙂‍↕️

Ok, I agree with you that ClassT doesn’t hit the mark. What I prefer doing generally (when I cannot use concepts) is to give the template parameters meaningful names. Considering that this function is very illustrative and doesn’t really have a proper purpose it is hard to pick such a template parameter name, meaning the one that actually makes sense. So here I picked the ClassT as a substitute but I agree that it is a bit stupid and if I would have thought longer about it I probably would have just used T here. Thanks for your comment!

For the win, my man

Unfortunately the answer to this comment is more complicated than I would like it to be. It has to do with how overload resolution is taken care of in C++, which is not trivial: en.cppreference.com/w/cpp/language/overload_resolution But the rule of thumb, at least the way I think about it, is that if we have a local object the compiler will prefer passing it by reference if an appropriate function overload exists. During this some implicit conversions can take place as well as some copies performed. My recommendation would be to write a simple example with some Foo function that has various overloads and see what the compiler does in each case to build more intuition. That being said if somebody who can explain it better stumbles upon this comment, I would like to find a nice and simple explanation for the future. 😅

@@CodeForYourself thank you, i really appreciate the answer, it surely provides a good starting point for me to try and understand this :) Keep up the great work, i discovered your channel with this video, and decided to start the whole course from the first lesson, even if I'm familiar with some of the basics of C++

@@francescobenacci6611 thanks for the kind words! Please mind that the first videos have a slightly different style from this one. I guess I converged to a style like this some time around the cmake video 😅

Welcome 😅