pimpl-idiom | 易学教程

Heap-free pimpl. Incorrect or superstition?

阅读更多关于 Heap-free pimpl. Incorrect or superstition?

问题 I am aspiring to separate interface from implementation. This is primarily to protect code using a library from changes in the implementation of said library, though reduced compilation times are certainly welcome. The standard solution to this is the pointer to implementation idiom, most likely to be implemented by using a unique_ptr and carefully defining the class destructor out of line, with the implementation. Inevitably this raises concerns about heap allocation. I am familiar with

pimpl for a templated class

阅读更多关于 pimpl for a templated class

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? 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 your class's implementation in a non-template base class (or encapsulated member object of some class). Solve

Pimpl idiom with inheritance

阅读更多关于 Pimpl idiom with inheritance

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 something else*/}; }; But I can't use pAimpl in B because it is A's private. So I see some ways to solve

Hiding a C++ class in a header without using the unnamed namespace

阅读更多关于 Hiding a C++ class in a header without using the unnamed namespace

I am writing a C++ header in which I define a class A { // ... }; that I would like to hide from the outside world (because it may change or even be removed in future versions of this header). There is also a class B in the same header that has an object of class A as a member: class B { public: // ... private: A a_; }; What is a proper way of hiding class A from the outside world? If I put the definition of A in an unnamed namespace, the compiler issues a warning, so I assume that, due to issues with internal linkage, I should do something else. You could do an inner class: class B { class A

Pimpl - Why can make_unique be called on an incomplete type

阅读更多关于 Pimpl - Why can make_unique be called on an incomplete type

问题 Why does the make_unique call compile? Doesn't make_unqiue require its template argument to be a complete type ? struct F; int main() { std::make_unique<F>(); } struct F {}; The question orignated from my "problem" with my PIMPL implementation : I do understand why the destructor has to be user declared and defined inside the cpp file for the Implementation class (PIMPL). But moving the constructor of the class containing the pimpl- still compiles. class Object {}; class CachedObjectFactory {

Pimpl idiom without using dynamic memory allocation

阅读更多关于 Pimpl idiom without using dynamic memory allocation

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. Warning: the code here only showcases the storage aspect, it is a skeleton, no dynamic aspect (construction, copy, move, destruction) has been taken into account. I would

How does the pimpl idiom reduce dependencies?

阅读更多关于 How does the pimpl idiom reduce dependencies?

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 do not have to be recompiled. Yet, I fail to see how this can truly be the case. Let's say I wanted to

Hiding a C++ class in a header without using the unnamed namespace

阅读更多关于 Hiding a C++ class in a header without using the unnamed namespace

问题 I am writing a C++ header in which I define a class A { // ... }; that I would like to hide from the outside world (because it may change or even be removed in future versions of this header). There is also a class B in the same header that has an object of class A as a member: class B { public: // ... private: A a_; }; What is a proper way of hiding class A from the outside world? If I put the definition of A in an unnamed namespace, the compiler issues a warning, so I assume that, due to

Is it possible to write an agile Pimpl in c++?

阅读更多关于 Is it possible to write an agile Pimpl in c++?

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 complex Impls in my current project. My question is, what effective ways are there to imply or template my

Should I use shared_ptr or unique_ptr

阅读更多关于 Should I use shared_ptr or unique_ptr

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 a hashmap for quick access while still being able to return copies of these objects to callers (as I