see this question: Effective C++ Item 23 Prefer non-member non-friend functions to member functions and also C++ Member Functions vs Free Functions You should prefer free functions, in the extent that it promotes loose coupling. Consider making it a member function only if it works on the guts of your class, and that you consider … Read more
You might consider something along these lines: An Interface class to minimize repeating declarations. The client will use the PublicImplementation class in their code. Pimpl.h #ifndef PIMPL_H_ #define PIMPL_H_ #include <memory> // std::unique_ptr class Interface { public: virtual ~Interface() {} virtual void func_a() = 0; virtual void func_b() = 0; }; class PublicImplementation { // … Read more
I’ve been making some objects using the pimpl idiom, but I’m not sure whether to used shared_ptr or unique_ptr. Definitely unique_ptr or scoped_ptr. Pimpl is not a pattern, but an idiom, which deals with compile-time dependency and binary compatibility. It should not affect the semantics of the objects, especially with regard to its copying behavior. … Read more
When writing a C++ class, it’s appropriate to think about whether it’s going to be A Value Type Copy by value, identity is never important. It’s appropriate for it to be a key in a std::map. Example, a “string” class, or a “date” class, or a “complex number” class. To “copy” instances of such a … Read more
I’d say that whether you do it per-class or on an all-or-nothing basis depends on why you go for the pimpl idiom in the first place. My reasons, when building a library, have been one of the following: Wanted to hide implementation in order to avoid disclosing information (yes, it was not a FOSS project … Read more
I believe that your test_help.cpp actually sees the ~Help() destructor that you declared default. In that destructor, the compiler tries to generate the unique_ptr destructor, too, but it needs the Impl declaration for that. So if you move the destructor definition to the Help.cpp, this problem should be gone. — EDIT — You can define … Read more
You are correct; the example seems to be missing an explicit template instantiation. When I try to run the example with a constructor and destructor for widget::impl on MSVC 2010 SP1, I get a linker error for pimpl<widget::impl>::pimpl() and pimpl<widget::impl>::~pimpl(). When I add template class pimpl<widget::impl>;, it links fine. In other words, GotW #101 eliminates … Read more
You define and document for your types what a ‘valid’ state is and what operation can be performed on moved-from objects of your types. Moving an object of a standard library type puts the object into an unspecified state, which can be queried as normal to determine valid operations. 17.6.5.15 Moved-from state of library types … Read more
Introduction The PIMPL is a private class that contains all of the implementation-specific data of the parent class. Qt provides a PIMPL framework and a set of conventions that need to be followed when using that framework. Qt’s PIMPLs can be used in all classes, even those not derived from QObject. The PIMPL needs to … Read more
So, I am wondering it this technique is really used in practice? Should I use it everywhere, or with caution? Of course it is used. I use it in my project, in almost every class. Reasons for using the PIMPL idiom: Binary compatibility When you’re developing a library, you can add/modify fields to XImpl without … Read more