pimpl-idiom

How do I use unique_ptr for pimpl?

巧了我就是萌 提交于 2019-11-27 03:42:25
Here is a simplification of what I'm seeing when I try to use unique_ptr for pimpl. I chose unique_ptr because I really want the class to own the pointer - I want the lifetimes of the pimpl pointer and the class to be the same. Anyway, here is the header: #ifndef HELP #define HELP 1 #include <memory> class Help { public: Help(int ii); ~Help() = default; private: class Impl; std::unique_ptr<Impl> _M_impl; }; #endif // HELP Here is the source: #include "Help.h" class Help::Impl { public: Impl(int ii) : _M_i{ii} { } private: int _M_i; }; Help::Help(int ii) : _M_impl{new Help::Impl{ii}} { } I

The Pimpl Idiom in practice

一个人想着一个人 提交于 2019-11-27 02:49:41
There have been a few questions on SO about the pimpl idiom , but I'm more curious about how often it is leveraged in practice. I understand there are some trade-offs between performance and encapsulation, plus some debugging annoyances due to the extra redirection. With that, is this something that should be adopted on a per-class, or an all-or-nothing basis? Is this a best-practice or personal preference? I realize that's somewhat subjective, so let me list my top priorities: Code clarity Code maintainability Performance I always assume that I will need to expose my code as a library at some

Does the GotW #101 “solution” actually solve anything?

白昼怎懂夜的黑 提交于 2019-11-26 18:58:22
First read Herb's Sutters GotW posts concerning pimpl in C++11: GotW #100: Compilation Firewalls (Difficulty: 6/10) GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10) I'm having some trouble understanding the solution proposed in GotW #101. As far as I can understand, all the problems laboriously solved in GotW #100 are back with a vengeance: The pimpl members are out-of-line templates, and the definitions are not visible at the point of use (in class widget 's class definition and implicitly generated special member functions of widget ). There aren't any explicit instantiations

Should I use shared_ptr or unique_ptr

北慕城南 提交于 2019-11-26 10:57:10
问题 I\'ve been making some objects using the pimpl idiom, but I\'m not sure whether to use std::shared_ptr or std::unique_ptr. I understand that std::unique_ptr is more efficient, but this isn\'t so much of an issue for me, as these objects are relatively heavyweight anyway so the cost of std::shared_ptr over std::unique_ptr is relatively minor. I\'m currently going with std::shared_ptr just because of the extra flexibility. For example, using a std::shared_ptr allows me to store these objects in

How do I use unique_ptr for pimpl?

自作多情 提交于 2019-11-26 10:39:18
问题 Here is a simplification of what I\'m seeing when I try to use unique_ptr for pimpl. I chose unique_ptr because I really want the class to own the pointer - I want the lifetimes of the pimpl pointer and the class to be the same. Anyway, here is the header: #ifndef HELP #define HELP 1 #include <memory> class Help { public: Help(int ii); ~Help() = default; private: class Impl; std::unique_ptr<Impl> _M_impl; }; #endif // HELP Here is the source: #include \"Help.h\" class Help::Impl { public:

What constitutes a valid state for a “moved from” object in C++11?

与世无争的帅哥 提交于 2019-11-26 10:34:21
I've been trying to wrap my head around how move semantics in C++11 are supposed to work, and I'm having a good deal of trouble understanding what conditions a moved-from object needs to satisfy. Looking at the answer here doesn't really resolve my question, because can't see how to apply it to pimpl objects in a sensible way, despite arguments that move semantics are perfect for pimpls . The easiest illustration of my problem involves the pimpl idiom, like so: class Foo { std::unique_ptr<FooImpl> impl_; public: // Inlining FooImpl's constructors for brevity's sake; otherwise it // defeats the

Pimpl idiom vs Pure virtual class interface

半城伤御伤魂 提交于 2019-11-26 09:05:23
问题 I was wondering what would make a programmer to choose either Pimpl idiom or pure virtual class and inheritance. I understand that pimpl idiom comes with one explicit extra indirection for each public method and the object creation overhead. The Pure virtual class in the other hand comes with implicit indirection(vtable) for the inheriting implementation and I understand that no object creation overhead. EDIT : But you\'d need a factory if you create the object from the outside What makes the

The Pimpl Idiom in practice

∥☆過路亽.° 提交于 2019-11-26 08:47:36
问题 There have been a few questions on SO about the pimpl idiom , but I\'m more curious about how often it is leveraged in practice. I understand there are some trade-offs between performance and encapsulation, plus some debugging annoyances due to the extra redirection. With that, is this something that should be adopted on a per-class, or an all-or-nothing basis? Is this a best-practice or personal preference? I realize that\'s somewhat subjective, so let me list my top priorities: Code clarity

Does the GotW #101 “solution” actually solve anything?

青春壹個敷衍的年華 提交于 2019-11-26 06:43:23
问题 First read Herb\'s Sutters GotW posts concerning pimpl in C++11: GotW #100: Compilation Firewalls (Difficulty: 6/10) GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10) I\'m having some trouble understanding the solution proposed in GotW #101. As far as I can understand, all the problems laboriously solved in GotW #100 are back with a vengeance: The pimpl members are out-of-line templates, and the definitions are not visible at the point of use (in class widget \'s class definition

What constitutes a valid state for a “moved from” object in C++11?

◇◆丶佛笑我妖孽 提交于 2019-11-26 01:53:49
问题 I\'ve been trying to wrap my head around how move semantics in C++11 are supposed to work, and I\'m having a good deal of trouble understanding what conditions a moved-from object needs to satisfy. Looking at the answer here doesn\'t really resolve my question, because can\'t see how to apply it to pimpl objects in a sensible way, despite arguments that move semantics are perfect for pimpls. The easiest illustration of my problem involves the pimpl idiom, like so: class Foo { std::unique_ptr