PIMPL技巧

PIMPL（Pointer to IMPLementation）是一种设计模式，也被称为“编译器实现”或“Opaque Pointer”模式。它是一种用于隐藏类的内部实现细节的C++编程技巧。PIMPL的核心思想是将类的实现细节封装在一个独立的私有类中，并在公共接口类中使用指针来引用这个私有类的对象。这种方法的优点包括：

1. 封装：PIMPL将类的实现细节从公共接口中分离出来，使公共接口更加干净和易于理解。

2. 隐藏实现：PIMPL允许在不影响公共接口的情况下更改类的实现细节。这样，您可以改进和优化类的内部结构，而无需修改外部代码。

3. 降低编译依赖性：通过将实现细节放在一个独立的编译单元中，PIMPL可以减少编译依赖性。当实现细节发生变化时，只需重新编译实现细节的源文件，而不需要重新编译使用类的客户端代码。

案例：

// MyClass.h
class MyClassImpl; // Forward declaration

class MyClass {
public:
    MyClass();
    ~MyClass();

    void doSomething();

private:
    MyClassImpl* pImpl; // Private pointer to implementation
};

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// MyClass.cpp
#include "MyClass.h"

// Private implementation class
class MyClassImpl {
public:
    void doSomethingPrivate() {
        // Implementation details go here
    }
};

MyClass::MyClass() : pImpl(new MyClassImpl) {}

MyClass::~MyClass() {
    delete pImpl;
}

void MyClass::doSomething() {
    pImpl->doSomethingPrivate();
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

在这个示例中，MyClass 公共接口类中只包含一个指向 MyClassImpl 私有实现类的指针 pImpl。所有的实现细节都在 MyClassImpl 类中，并且在 MyClass 的成员函数中通过 pImpl 访问。

这种PIMPL模式的使用可以改善代码的可维护性，尤其是在需要隐藏大量实现细节或者在库的接口设计中。它允许将库的实现细节隐藏起来，以提供更稳定的公共接口。

Q1.class增加private/protected成员时，使用此class的相关 .cpp(s) 需要重新编译

假设我们有一个A.h(class A)，並且有A/B/C/D 4个.cpp引用它，他们的关系如下图：

如果A class增加了private/protected成员，A/B/C/D .cpp全部都要重新编译。因为make是用文件的时间戳记录来判断是否要从新编译，当make发现A.h比A/B/C/D .cpp4个文件新时，就会通知compiler重新编译他们，就算你的C++ compiler非常聪明，知道B/C/D文件只能存取A class public成员，make还是要通知compiler起来检查。三个文件也许还好，那五十个，一百个呢？
案例
解決方法：

//a.h
#ifndef A_H
#define A_H
 
#include 
 
class A
{
public:
    A();
    ~A();
     
    void doSomething();
     
private:    
      struct Impl;
      std::auto_ptr<impl> m_impl;
};
 
#endif
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

有一定C++基础的人都知道，使用前置声明(forward declaration)可以减少编译依赖，这个技巧告诉compile指向 class/struct的指针，而不用暴露struct/class的实现。在这里我们把原本的private成员封裝到struct A::Impl里，用一个不透明的指针(m_impl)指向他，auto_ptr是个smart pointer(from STL)，会在A class object销毁时连带将资源销毁还给系统。
a.cpp 如下：

//a.cpp
#include 
#include "a.h"
 
struct A::Impl
{
    int m_count;
    Impl();
    ~Impl();
    void doPrivateThing();
};  
 
A::Impl::Impl():
    m_count(0)
{
}
 
A::Impl::~Impl()
{
}          
 
void A::Impl::doPrivateThing()
{
    printf("count = %d\n", ++m_count);
}    
 
A::A():m_impl(new Impl)
{
}      
 
A::~A()
{
} 
 
void A::doSomething()
{
    m_impl->doPrivateThing();    
}    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

上面我们可以看到A private数据成员和成员函数全部被封裝到struct A::Impl里，如此一来无论private成员如何改变都只会重新编译A.cpp，而不会影响B/C/D.cpp，当然有时会有例外，不过大部分情况下还是能节约大量编译时间，项目越大越明显。

Q2.定义冲突与跨平台编译

如果你运气很好公司配給你8 cores CPU、SSD、32G DDRAM，会觉得PIMPL是多此一举。
但定义冲突与跨平台编译问题不是电脑牛叉能够解決的，举个例子，你想在Windows上使用framework(例如 Qt)不具备的功能，你大概会这样做：

//foo.h
#ifndef FOO_H
#define FOO_H
 
#include 
 
class Foo
{
 
public:
    Foo();
    ~Foo();
    void doSomething();
     
private:
    HANDLE m_handle;
     
};
 
#endif
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Foo private数据成员: m_handle和系统相关，某天你想把Foo移植到Linux，应为Linux是用int来作为file descriptor，为了与Windows相区分，最直接的方法是用宏：

//foo.h
#ifndef FOO_H
#define FOO_H
 
#ifdef _WIN32
#include 
#else
#include 
#include 
#include 
#endif
 
class Foo
{
 
public:
    Foo();
    ~Foo();
    void doSomething();
     
private:
 
#ifdef _WIN32    
    HANDLE m_handle;
#else
    int m_handle;
#endif    
     
};
 
#endif
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

这样做会有什么问题？
1.windows.h是个巨大的header file，有可能会增加引用此header file的其他.cpp(s)编译时间，而实际上这些.cpp並不需要windows.h里面的内容。
2.windows.h会与framework冲突，虽然大部分的framework极力避免发生这种事情，但往往项目变得越来越大后常常出现这类编译错误，(Linux也可能发生)。
3.对于Linux用户，Windows那些header file是多余的，对于Windows用户Linux header files是多余的，沒必要也不该知道这些细节。

原文链接:https://blog.csdn.net/caoshangpa/article/details/78590826