pimpl-idiom

问题 The code would work file as long as I don't move the definition of constructor (of B ) to the header B.h . B.h class Imp; //<--- error here class B{ public: std::unique_ptr<Imp> imp; B(); //<--- move definition to here will compile error ~B(); //// .... other functions .... }; B.cpp #include "B.h" #include "Imp.h" B::B(){ } ~B::B(){ } Imp.h class Imp{}; Main.cpp (compile me) #include "B.h" Error: deletion of pointer to incomplete type Error: use of undefined type 'Imp' C2027 I can somehow

问题 I have read a bit about the PIMPL idiom and was wondering - is it any different to forward declaring the dependent type(s)? If so: When will I prefer using that over a forward declaration? Do these two versions differ in their compilation time? Is one of them more scalable than the other? Specifically consider a class Foo that is dependent on Bar (should have a member of type Bar ). Foo.h with forward declaration: class Bar; class Foo { public: Foo(); private: Bar* _bar; }; Foo.h with PIMPL:

问题 Per my previous question, I wish that a boost::shared_ptr<A> was actually a subclass of A (or perhaps A* ) so that it could be used in methods that took A* as their argument. Consider the following class: class A { public: A(int x) {mX = x;} virtual void setX(int x) {mX = x;} virtual int getX() const {return mX;} private: int mX; }; In the previous question, I proposed the creation of a SharedA object to take care of this, and presumably it does. class SharedA : public A { public: SharedA(A*

问题 Sometimes, C++'s notion of privacy just baffles me :-) class Foo { struct Bar; Bar* p; public: Bar* operator->() const { return p; } }; struct Foo::Bar { void baz() { std::cout << "inside baz\n"; } }; int main() { Foo::Bar b; // error: 'struct Foo::Bar' is private within this context Foo f; f->baz(); // fine } Since Foo::Bar is private , I cannot declare b in main . Yet I can call methods from Foo::Bar just fine. Why the hell is this allowed? Was that an accident or by design? Oh wait, it

问题 Is it somehow possible, to accomplish the following: x.hpp - this file is included by many other classes class x_impl; //forward declare class x { public: //methods... private: x_impl* impl_; }; x.cpp - the implementation #include <conrete_x> typedef concrete_x x_impl; //obviously this doesn't work //implementation of methods... So basically, I want the users to include the file x.hpp , but be unaware of the conrete_x.hpp header. Since I can use concrete_x only by a pointer and it appears

问题 First, the big picture. I have a Logger class. I've created a simplified interface for the class, and created a library for the interface. I'd like to use pimpl to hide the Logger class implementation, so the user doesn't need the Logger's headers. I'm having a bad time with template functions... The Logger header is defined like this /* Logger.h */ class Logger { public: virtual ~Logger(){}; public: template <typename... Args> void log(const char* fmt, const Args&... args) { printf(fmt,

问题 I want to use the d-pointer in a derived class with the help of Q_D macro. Here is my parent class: class DIGIKAM_EXPORT GraphicsDImgView : public QGraphicsView { Q_OBJECT public: class GraphicsDImgViewPrivate; protected: GraphicsDImgViewPrivate* const d_ptr; protected: Q_DECLARE_PRIVATE(GraphicsDImgView) }; and my GraphicsDImgViewPrivate class: class GraphicsDImgView::GraphicsDImgViewPrivate { public: GraphicsDImgViewPrivate() { scene = 0; item = 0; layout = 0; cornerButton = 0; panIconPopup

问题 I apologize for the large amount of code required to demonstrate the issue. I am having a problem using the pimpl idiom with std::unique_ptr. Specifically the problem seems to occur when one class (which has pimpl'ed implementation) is used as member data in another composite class with pimpl'ed implementation. Most of the answers I've been able to find deal with a lack of explicit destructor declaration, but as you can see here, I have declared and defined the destructors. What is wrong with

问题 I am learning PIMPL idiom. One of its advantage is binary compatibility. I am wondering what the advantages of binary compatibility are. Thanks! 回答1: It avoids the Fragile Binary Interface Problem. It goes like this: Program uses library. User upgrades library. Upgrade changes something in the library's binary interface. Program now doesn't work until it is recompiled because it was built to the old binary interface. One of the advantages of the PIMPL idiom is that it allows you to move

问题 // main_pimpl_sample.cpp #include "pimpl_sample.hpp" using namespace std; int main() { pimpl_sample p; return 0; } // pimpl_sample.cpp #include "pimpl_sample.hpp" struct pimpl_sample::impl { }; pimpl_sample::pimpl_sample() : pimpl_(new impl) { } // pimpl_sample::~pimpl_sample() // cause problem if missed // {} // pimpl_sample.hpp #if !defined (PIMPL_SAMPLE) #define PIMPL_SAMPLE #include <boost/scoped_ptr.hpp> class pimpl_sample { struct impl; boost::scoped_ptr<impl> pimpl_; public: pimpl