Classes Part 30 - pIMPL (pointer to implementation) - More Stable APIs| Modern Cpp Series Ep. 67
Vložit
- čas přidán 10. 06. 2022
- ►Full C++ Series Playlist: • The C++ Programming La...
►Find full courses on: courses.mshah.io/
►Join as Member to Support the channel: / @mikeshah
►Lesson Description: In this lesson I talk about an important idiom that allows us to hide our implementation details in our classes. The pointer to implementation (pIMPL) idiom stores private data members and member functions in a class, while also limiting the pIMPL class's scope. This can be a way to create a more stable ABI for your applications, and even save compile times. The cost may be an additional level of indirection, and managing code in a .cpp file. In general, I would urge folks who have long lived codebases to consider this idiom.
►CZcams Channel: / mikeshah
►Please like and subscribe to help the channel! - Věda a technologie
Incredible explanation, I was struggling to understand the benefits of this tecnique but your video clarified everything :D
Cheers -- I'm happy to hear that!
Nice!! Thank you for pointing this video to me. This is helpful!
Cheers!
Great video. Wonderfully explained as always. Thank you.
Cheers, thank you Dhanush!
Great Explanation and thanks for covering this.
Cheers, thank you for the kind words!
Excellent video. Crisp and clear. I always had a concern that my company's legacy codes are exposing so much internal details to the customers. I am going to implement this approach.
Cheers!
Your vidoes are very insightful. Please continue making more videos. Thank ypu
Thank you for the kind words Akash!
very well made video. thanks for uploading.
Thank you, my pleasure!
Fantastic Video thanks champ!
Cheers!
hey mike! can you do a video on the type erasure idiom? Also where do you learn these idioms from? Thanks!
Will add that to the wish list! Idioms are learned over time through books, conference talks, and CZcams! :)
Very good, bro!
Thank you for the kind words!
Related to 10:32, a std::unique_ptr was chosen over a std::shared_ptr because the Person class will be the only point of access to m_impl? I'm exploring in general what are the trade-offs between shared vs unique.
This reminds me I need to rewatch czcams.com/video/DHu0tv2qTYo/video.html and the other related smart pointer videos.
Correct! Generally prefer unique over shared for both performance and safety -- unless you know that the data must be shared. For pImpl pattern, unique makes sense as you have suggested :)
This should be your next jeopardy quiz shhhh 🤫 (I confess I haven't finished you jeopardy video yet and wanted to wait so you may already have this in there)
@@damondouglas Not a bad idea. It will probably be worthwhile to have a few more review lessons along the way too :)
great explanation.
thx.
but could you clarify one thing.
how do you actually hide your implementation from customers?
do you encrypt your cpp file, or do anything else? thx
Typically since the code is in the .cpp file the binary code is 'hidden' from customers. Folks may also obfuscate code and run a command like 'strip' to further obfuscate the generated code.
What's the real benefit of this idiom other than just interface separation or hiding. I guess child classes of this class will have Impact.
Information hiding is the big one. The other major one would be abi stability, as a pointer will always be 8 bytes on a 64-bit system. So if you make changes to the class, those happen in the implementation, and the class size does not change.
So people don't like RAII, but are fine with pimpl?!
Both can be used together, pIMPL is useful for ABI stability and information hiding, and lazy initailization. RAII is one of the favorite features of C++ because it gives deterministic creation of objects, and ensures resources are closed when terminated or otherwise exceptions are thrown.