pimpl-idiom

问题 D has a fantastic module system which reduces compilation times dramatically compared to C++. According to the documentation D still provides opaque structs and unions in order to enable the pimpl idiom. My question is: How can I declare a nested struct (or union) in one module and define it in another one? What is the syntax for that? In C++ the header would look like this struct S { ... struct Impl; Impl * p; }; and the implementation file (cpp-file) would use some interesting-looking ::

问题 What is the advantage of having a free function (in anonymous namespace and accessible only in a single source file) and sending all variables as parameters as opposed to having a private class member function free of any parameters and accessing member variables directly? Thanks! header: Class A { int myVariable; void DoSomething() { myVariable = 1; } }; source: namespace { void DoSomething2(int &a) { a = 1; } } int A::SomeFunction() { DoSomething2(myVariable); // calling free function

问题 I want to use the pimpl idiom to avoid having users of my library need our external dependencies (like boost, etc) however when my class is templated that seems to be impossible because the methods must be in the header. Is there something I can do instead? 回答1: If the class is templated, your users essentially need to compile it (and this is literally true in the most widely-used C++ implementations) and so they need your external dependencies. The simplest solution is to put the bulk of

问题 we want to use pimpl idiom for certain parts of our project. These parts of the project also happen to be parts where dynamic memory allocation is forbidden and this decision is not in our control. So what i am asking is, is there a clean and nice way of implementing pimpl idiom without dynamic memory allocation? Edit Here are some other limitations: Embedded platform, Standard C++98, no external libraries, no templates. 回答1: Warning: the code here only showcases the storage aspect, it is a

问题 Consider the following: PImpl.hpp class Impl; class PImpl { Impl* pimpl; PImpl() : pimpl(new Impl) { } ~PImpl() { delete pimpl; } void DoSomething(); }; PImpl.cpp #include "PImpl.hpp" #include "Impl.hpp" void PImpl::DoSomething() { pimpl->DoSomething(); } Impl.hpp class Impl { int data; public: void DoSomething() {} } client.cpp #include "Pimpl.hpp" int main() { PImpl unitUnderTest; unitUnderTest.DoSomething(); } The idea behind this pattern is that Impl 's interface can change, yet clients

问题 I've been playing with the Pimpl idiom and reaping all sorts of benefits from it. The only thing I haven't been too keen on is the feeling I get when I define the functions. Once in the header (P def) Once at the top of the .cpp (Impl def) Once in the middle of the .cpp (Impl Impl) Once at the lower end of the .cpp (P Impl) I really enjoy cutting down code disparity and redundancy, and I feel like my code is less than well oiled when I have to add or change functions in even relatively

问题 I've been playing with the Pimpl idiom and reaping all sorts of benefits from it. The only thing I haven't been too keen on is the feeling I get when I define the functions. Once in the header (P def) Once at the top of the .cpp (Impl def) Once in the middle of the .cpp (Impl Impl) Once at the lower end of the .cpp (P Impl) I really enjoy cutting down code disparity and redundancy, and I feel like my code is less than well oiled when I have to add or change functions in even relatively

问题 In this question I asked "pimpl: shared_ptr or unique_ptr" I've been convinced that the proper usage of the pimpl idiom is to use a unique_ptr , not a shared_ptr . It should act to the user as if there is no pointer at all, whereas quite clearly the shared_ptr introduces aliasing upon copying, which definitely acts like a pointer. So, lets say a user wants to create a shared_ptr to my pimpl object (say if they want actually want multiple aliases to it). For example: shared_ptr<my_pimpl> p(new

问题 I recently switched back from Java and Ruby to C++, and much to my surprise I have to recompile files that use the public interface when I change the method signature of a private method, because also the private parts are in the .h file. I quickly came up with a solution that is, I guess, typical for a Java programmer: interfaces (= pure virtual base classes). For example: BananaTree.h: class Banana; class BananaTree { public: virtual Banana* getBanana(std::string const& name) = 0; static

问题 I want to use pimpl idiom with inheritance. Here is the base public class and its implementation class: class A { public: A(){pAImpl = new AImpl;}; void foo(){pAImpl->foo();}; private: AImpl* pAImpl; }; class AImpl { public: void foo(){/*do something*/}; }; And I want to be able to create the derived public class with its implementation class: class B : public A { public: void bar(){pAImpl->bar();}; // Can't do! pAimpl is A's private. }; class BImpl : public AImpl { public: void bar(){/*do