References
C++ Coding Standard
這本書的中文版不知道是不是翻譯問題，還是原作就有這種傾向，有些咬文嚼字的很不好懂。
Exceptional C++
這本比上面那本容易理解的多，有提到 PIMPL 實作上需要注意的地方，可惜的是已經絕版了，有趣的是前面那本作者之一也是本書作者。
上面這兩本其實缺乏的是實務面的範例，如果缺乏實務面的說明，PIMPL 對初學者來講就只是炫技罷了，本文多少做了一些補充。
PIMPL (Pointer to Implementation ) 技巧已經出現十幾年了，可是小弟的職業生涯中卻很少看到有人使用，決定來寫篇文章推廣一下。這個手法可以解決/改善 C++ coding 常碰到的 2 大問題：
class 增加 private/protected member，使用此 class 的相關 .cpp(s) 需要重新編譯
定義衝突與跨平台編譯問題
Q1. class 增加 private/protected member，使用此 class 的相關 .cpp(s) 全部需要重新編譯
假設我們有一個 A.h(class A)，並且有 A/B/C/D 4 個 .cpp 引用他，他們的關係如下圖：
假如 A class 增加了 private/protected member，A/B/C/D.cpp 全部都要重新編譯。因為 make 是用檔案的時間戳記來判斷是否要重新編譯，當 make 發現 A.h 比 A/B/C/D.cpp 4個檔案新，就會呼叫 compiler 重新編譯他們，就算你的 C++ compiler 非常聰明，知道這 B/C/D 檔案只能存取 A class public member，make 還是要把 compiler 叫起來檢查。三個檔案也許還好，那五十個，一百個呢？
//a.h
#ifndef A_H
#define A_H
#include <memory>
class A
{
public:
A();
~A();
void doSomething();
private:
struct Impl;
std::auto_ptr<impl> m_impl;
};
#endif
C++ 有一定程度的人都知道，在尚未取用指標指向的實體前，我們可以用 forward declaration 的技巧告訴 compiler 這是個「指向 class/struct 的指標」，而不用顯露 struct/class 的佈局。
在這裡我們把原本的 private member 封裝到 struct A::Impl 裡，用一個不透明的指標(m_impl) 指向他，auto_ptr 是個 smart pointer(from STL)，會在 A class object 銷毀時連帶將資源銷毀還給系統。
a.cpp 如下
//a.cpp
#include <stdio.h>
#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();
}
上面我們可以看到 A private data/function member 全部被封裝到 struct A::Impl 裡，如此一來無論 private member 如何改變都只會重新編譯 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 <windows.h>
class Foo {
public:
Foo();
~Foo();
void doSomething();
private:
HANDLE m_handle;
};
#endif
Foo private data member: m_handle 對應到某個特別的檔案或裝置，某天你想把 Foo 移植到Linux，因為 Linux 是用 int 作為 file descriptor，為了與 Windows 的定義區隔，最直接的手段就是用巨集：
//foo.h
#ifndef FOO_H
#define FOO_H
#ifdef _WIN32
#include <windows.h>
#else
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#endif
class Foo {
public:
Foo();
~Foo();
void doSomething();
private:
#ifdef _WIN32
HANDLE m_handle;
#else
int m_handle;
#endif
};
#endif
這樣做會有什麼問題？
windows.h 是個巨大的 header file，有可能會增加引用此 header file 的其他 .cpp(s) 編譯時間，而實際上這些 .cpp 並不需要 windows.h 裡面的資訊。
windows.h 會與 framework 衝突，雖然大部分的 framework 極力避免發生這種事，但往往專案成長變大後常常出現這類編譯錯誤(Linux 也可能發生)。
對於 Linux 用戶，Windows 那些 header file 是多餘的，對於 Windows 用戶 Linux header files 是多餘的，沒必要也不該知道這些細節。
Please minimize your header file!
「請最小化你的 header file」，這是站長 10 幾年來最重要的工作心得之一。不過有些人會質疑那我不是不能用 inline function？也許是站長孤陋寡聞，站長 10 幾年來還沒碰過非得用 inline 才能解決的問題，而且實務經驗中如 C++ Builder 甚至用 inline 還會發生奇怪的 bug(改成一般的 member function 就好了)，事實上很多認為用 inline 會加快的程式都是自由心證缺乏嚴格測試。目前非得放在 header file 大概只有 template，但實務上的很少看過有人自己實作 template，善用 STL 的人就已經不多了。
Yunfei Zu 前辈对 Pimpl 的解释
C+＋的Pimpl惯用法或者说Pimpl模式，又被称为编译防火墙，是一种在头文件中隐藏实现的方式。Pimpl很古老，可能在标准C+＋诞生之前就有了这种用法，其间争论也早已尘埃落定，用和不用各有利弊，主要还是看组织内部的规范和项目的需要。最近Team一直同时在两个subsystem下工作，两个subsystem的code base一个用了Pimpl一个没有用，是以在Team中产生了到底要不要用的争论。虽然SA的决定是维持现状，但还是总结下Pimpl的相关知识，以备参考。
Pimpl 没有固定的形式，有的很复杂，如Qt中的private class和D-Pointer的结构。而Team在项目中用到的相对很简单，只是一个智能指针加一个Inner Class, 基本结构如下。
// Foo.h
class Foo {
public:
Foo();
virtual ~Foo();
private:
class Pimpl;
boost::scoped_ptr<Pimpl> _pimpl;
};
// Foo.cpp
class Foo::Pimpl {
public:
// data or functions
}
Foo::Foo() : _pimpl(new Pimpl) {}
Foo::~Foo() {}
使用这种结构的好处：
成员变量的修改不会影响类的头文件，避免重新编译所有inclue类头文件的模块
类的头文件不需要include 成员变量的头文件，减少编译依赖，加快编译速度
更好的封装类的实现细节
而相应的缺点：
增加了代码复杂度
造成代码可读性下降
由于指针间接调用造成的性能下降
至于要不要使用Pimpl, 要视情况而定。如果你的工程更注重减少依赖，隐藏实现，Pimpl正适合你。相反如果你的工程中的类含有很多虚函数，又会被大量调用，最好考虑下Pimpl会不会带来性能问题。最近就遇到一个例子，一个库和Qt有冲突，在moc class的头文件中inclue这个库的头文件就会有编译问题。最后就是用Pimpl的方法解决了头文件的依赖。
