Thank you for this. I've read several articles and watched cpp con presentations. Your take on the subject was the best i've encountered yet all because you eased us in with the very basic building blocks first.
Thanks for the awesome video. I've been programming C++ for 25 years but non professionally. I used to think all the abstract programming design theories were just "corporate bloat". I had the mentality of "shut up and code!". But as you can imagine, projects became increasingly complex as project size grew. This forced many projects to go unfinished. I was CONSTANTLY having to rewrite code. Not to mention near full-rewrites... Stuff was near impossible to maintain or extend... the list goes on. Finally, I've been making a concerted effort to write maintainable code so I don't have to keep rewriting everything from scratch all the time! I definitely agree with your beginning of the video. I tried looking through some SOLID videos before but they were based on other languages. The implementations were quite different and definitely made the examples harder to relate to. Thanks again! I've subscribed and will definitely be checking out your other videos.
Nice and informative video. One suggestion to the terminology of "subclass" at 14:45 (At ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE--Z7EOWVkb3M.html). Things such as typename S::IpV4, S::IpV6 in C++ are called member type, while "subclass" typically means "derived class".
Thank you for this clear description. This is what I needed for my own Menu backend I have been working on. I was trying to figure out how to have a lot of options for overlapping functionality without having to have a ton of different classes or calls - I can wrap each base functionality into a component and use a builder like design to construct a composition class that has whatever is needed for a particular element. Sometimes I find the text book descriptions of things like this kinda hard to visualize, and the extremely simple sample code snippets too simple to show whats going on. I like these more moderately complex samples that actually show things at work and give room to think a bit about how data is being moved around to get where it needs to be.
Hi, as it's mentioned in the Github repo, yes, an API key that you pay for is required. It's not a plan-based subscription though, you pay as you go depending on how much you use it.
Nice presentation, I wouldn't expect anything else :) BTW, you should think of investing in a good mic and especially sound proofing where you record these videos
I'm looking forward to hearing about error handling and reporting lectures... and there are 12 lectures in this series? Wow, this is going to be a deep dive, excellent!
There are 12 more parts indeed, but you don't have to wait. You can already check them out on Udemy for free: www.udemy.com/course/error-reporting-in-cpp/ The best part? There are also interactive coding exercises for each technique. :}
Correct. Alternatively, if you really want to avoid creating a new builder object (for whatever reason), you could instead store all the different "attributes" in the `Menu` class and only create a `Impl` object when someone calls the `build()` function. In that case the `withBorder`, `addOption` etc methods of the `Builder` class would merely set member variables and only create an `Impl` object upon the call of `build`. If you'd like us to discuss with more details and potentially code examples, please start an "issue" or a "discussion" in the GitHub repo (github.com/platisd/cpp-builder-pattern).
I've listened to Dimitris talk in C++ Athens meetup. This is a brilliant session covering SFINAE; its alternatives and some cool techniques with it (I wouldn't know). I'm planning to revisit this video again for referring some advanced topics discussed whenever I need. I would recommend this video as a great watch to all C++ enthusiasts.
What about you open an issue on the Github repository? ( github.com/GallopingSnaiI/SmartCar ) As you can probably tell, I have no way of imagining what the error you're encountering is and RU-vid isn't the best place for such discussions. Also, please tag @platisd so I can get a notification.
A "project level" similarity, no. This tool compares files to other files. You might be able infer project-level similarity with some modifications to the script, but I haven't thought it through.
I believe you mentioned that this is a technique appropriate to specialisation at link-time, i.e., if you wanted to use a SPI comms interface instead of I2C for an application, that would require the source code for Gyroscope::GyroscopeImpl in Gyroscope.cpp to be physically different. Is that correct? If you wanted to decide, at run-time, whether to use SPI or I2C, would you extract an interface, say CommsDevice, implemented by I2cCommsDevice and SpiCommsDevice with a pointer to the interface held in the GyroscopeImpl class, and passed in via, e.g. its constructor (or a setter function)? (Sorry to use Java terms so much, but they are clearer than C++ - 'interface' - > 'pure virtual base class' etc 😂).
I am a bit confused because `Gyroscope.cpp` doesn't include any `GyroscopeImpl` and then you lost me about the part where a pointer is being passed via a setter or constructor. I suspect passing anything via the constructor/setter will defeat the purpose of hiding the implementation, but I could be misunderstanding you. How about this: RU-vid isn't the right platform for such discussions, what if we take it on GitHub instead? Could you please open an issue in the repo (github.com/platisd/cpp-pimpl-tutorial) add any code snippets or links to files you think are necessary and then I promise you we will get to the bottom of this. :)
@@TheRealBigYang aha I see. `struct` is used in the examples to skip one line of code for the `public` access modifier needed in the case of classes. Other than that, it's a matter of convention. The only difference, after all, between classes and structs in C++ is their default visibility.
