pimpl（又稱：編譯器防火牆）習慣用於縮短編譯時間，代價是可讀性和一點運行時性能。目前一個項目需要很長時間才能編譯，如何衡量最好的pimpl候選人？如何衡量pimpl候選人？
我有使用pimpl的經驗，縮短了一個項目的編譯時間，從兩個小時到十分鐘，但我這樣做只是遵循我的直覺：我推理出這樣的類頭文件，其中包括：（1）很多源代碼（2）複雜/模板類，是使用疙瘩成語的最佳人選。
有沒有一種工具可以客觀地指出哪些類是好的pimpl候選者？
這是事實，Pimpl對增量編譯很有用。
但是使用Pimpl的主要原因是爲了保持ABI兼容性。這是我以前的公司對API中幾乎所有公共類的規則。
其他的好處是，你也可以將你的庫作爲一個包含頭部的包來分發，而不暴露實現細節。
爲此我會說：儘可能使用Pimpl。
一個很好的Qt的平普爾實施細則和好處的文章：
的編譯時間問題必須得到解決代碼觸摸頻率。不經常更改的部分可以在庫中編譯並在本地存儲庫中發佈，以便其他項目按版本進行引用。
感謝saad在這些方面給我啓發。不過，我的問題是，如何衡量使用pimpl會在編譯時增加最多的地方。最接近這個答案的是你的'通過代碼觸摸頻率將你的大項目分成小項目'的建議。我的問題是：'你如何衡量？' – richelbilderbeek
OT：我一直的印象是，要使用PIMPL的主要原因是爲了在聯合國臃腫從實施細則的公共接口。無論如何， – sjaustirni
這個很好的問題是否嘗試使用預編譯頭文件來查看編譯時的性能增益是多少？ – Christophe
@Christophe：是的，我已經使用了預編譯頭文件。我原來的問題是：'如何測量預編譯頭部候選者？' – richelbilderbeek