https://www.potatomedia.co/s/cJqiP7d
為什麼身邊的 #M_Power 車主總是要挑戰大家的肺活量呢?
#一口氣唸完改裝清單Challenge
M Performance-黑水箱護罩
M Performance-黑葉子板飾板
M Performance-不鏽鋼油門煞車踏板組
M Performance-LED迎賓門檻
M Performance-Carbon排檔飾板組
M Performance-Alcantara 電子方向盤
M Performance-方向盤(消光Carbon飾蓋)
M Performance-M4碳纖維陶瓷煞車
HRE P101單鍛 20"
Akrapovic中尾段本體
Akrapovic不繡鋼金屬觸媒(已換下)
Akrapovic無線遙控器
倒車雷達開關面板
Eventuri Carbon Fiber高流量進氣
FTP Charge Pipe + Boost Pipe
WT中冷
DINAN防傾桿
OHLINS倒插式避震
日本CPM平衡桿-Studie
3D Design F87 M2 Program
英國HPP底盤全車結構
Rush Plux當派
MICHELIN - PS4S
FALL-LINE前後李仔串
FALL-LINE後可調角度連桿
M Performance腳踏墊
原廠BMW尾門高亮黑M Logo
Performance Alcantara鑰匙包
全車犀牛皮+隔熱紙+前檔防爆膜
鍍膜四階
南極星 GPS-1888BT
Thinkware F770 雙鏡頭 WIFI行車紀錄器
BMW原廠後行李箱橡膠墊
BMW原廠車門橡膠
hpp檔 在 [心得] 改善C++ 編譯效率的方法- 精華區C_and_CPP 的美食出口停車場
很久以前在 Exceptional C++ 上看過「編譯防火牆」的技術，
最近常用到這個東東。
C++ 似乎傾向把所有的負擔都推給 complier，而極力爭取設計
的靈活性及執行期的效率。這從語言本身許多豐富的機制可以
看出。
但是，如果專案的規模稍微大些，編譯所花去的時間就很可觀，
也許只是修改一個小地方的定義，卻牽一髮動全身，幾乎大部
份的檔案都要重新編譯過。
這裏討論一下改善編譯效率的幾個方法（除了改善硬體設備之
外）
首先，和語言無關的，最普通的方法就是把專案中很少變動的
模組以 dll/lib的方式獨立出來。當然，如果模組常常變化，
獨立成 lib 就沒啥好處，還容易造成錯誤。
另外，使用快取的功能或編譯器廠提供的特殊方法，也是有效
的手段。
至於，與 C++ 有關的特殊方法，其實只有一句話：
「將模組之間的依存性最小化」
如果在某個標頭檔（.h／.hpp）中 include 另外一個模組，
例如在 A 模組的標頭檔 include B 模組，那麼一旦 B 模組
的介面（.h 部份）有任何改變，不但 A 模組要重新編譯，
所有 include A 模組介面的其他模組，也必須重新編譯。
但如果 A 模組只是在實作檔（通常是.cpp） include B 模
組的介面，那麼 A 模組與 B 模組的介面依存性就降低了許
多，至少引用 A 模組介面的其他模組不必再重新編譯。
不要小看這一點，我常看到許多人寫程式，只求方便，想要
什麼功能，就一個一個 include 進來，其實有很多是非必要
的，或只要稍微花點小力氣，就可以降低依存性。這種習慣
在寫小程式或許完全沒差，但如果進行的是規模比較大的專案
，聚沙成塔，好習慣和壞習慣所累積的差異就會愈來愈明顯。
我曾經做過一個專案，我同事負責的部份，只要小小改動一
個定義檔，就要編譯超過半小時（如果整個重新編譯至少
一個小時以上是跑不掉的），為此我把他的專案照此原則簡
單的修改，移除了某些不必要的依存關係，小改動後再重編
的時間就節省了超過一半。
根據上述的原理，一個最簡單的降低模組依存性的法則：
「如果可以用前置宣告代替 include，就不要 include」
例如，有一個 Client 模組，在 Network 模組中會被用到，後
者有個介面如下：
void Send(Client *, char const *buf, int buflen);
因為在 Network 的介面中，只用到 Client 的指標，並不需要
參考到 Client 的定義，所以 include Client 模組就是多餘的
了，只需要一個前置宣告即可：
class Client;
這是最基本的手法。除了指標之外，如果介面只用到 reference
或是某些經過 extern 或 typedef 宣告（定義）出來的東西，
也可以不需要直接 include 整個模組，只要再次「聲明」一次
即可。C++ 標準程式庫中的 <iosfwd> 就是個好例子。（主要
由於不能直接動 namespace std 的主意）
◎編譯防火牆 Pimpl 手法
簡單描述一下 Exceptional C++ 所介紹的 Pimpl 手法：
class X
{
public :
... // pubilc interface
private :
class XImpl *Impl;
};
其實原理很簡單，就是把 X 的實作（private）的部份，委托給另
一個 class XImpl，這樣，不論 XImpl 怎麼實現，class X 的介面
都不會受到影響。如此一來，當 XImpl 的實現改變時，include X
介面的模組，就不需要重新編譯（只要重新連結）。
有一種中介軟體（例如：CORBA、COM……等等）的技術，就是遵循某
些介面設計的規則，把這種「只要介面不變，無論實作怎麼改變，用戶
都可以不用改變」的設計思維發揮到極限。雖然中介軟體的主要目的
在於分散式系統之間的物件互相溝通，但它的設計傾向，著重於二進
位碼的重用性，這和 C++ 極度傾向倚賴編譯器（也就是 C++ 原始碼
的移植性）的理念有著根本的不同。（當然，兩者的出發點和目的不
同，所以設計傾向當然不同）
不過，某些時候，當編譯效率不容忽視，那麼中介軟體的「遵循介面
設計法則」的精神，也就值得借鏡。
再舉個例子，由於 C++ Templates 的特性太過複雜，絕大多數的編譯
器廠都沒能實現 export 關鍵字的功能（我知道的只有 Comeau 和其他
極少數的 C++ Complier 有支援），造成 template 程式碼必須放在
標頭檔中，所以如果大量使用 template 機制，是很耗費編譯時間的。
不幸的是 C++ Standard，包括俗稱 STL 等常用的容器類，幾乎都是
template，而 namespace std 又不能拿來前置宣告，一旦要使用標準
容器，就只好「直接 include 進來」，例如：
// 檔案： MyClass.hpp
#include <vector>
class MyClass
{
public :
...
private :
...
std::vector<int> Container;
};
像這種設計是很常見的。當然，可以效法前面 Pimpl 的手法，來個
MyClassImpl，避免在 .hpp 檔 include vector 進來。但是，也許
MyClass private 的其他成員，大都是些基礎類型，或是某些不影響
編譯效率的物件，那為了避免在 .hpp 引入 vector，而整個委託給
MyClassImpl，實在是太過麻煩了！
◎Pimpl 手法的變型應用
因此，一個折衷的辦法就是不動其他的部份，只針對 vector 來處理
，以下是一個簡單的實現方法：
// 檔案： MyClass.hpp
class MyClass
{
public :
~MyClass();
MyClass();
...
private :
...
class Container *pContainer;
};
// 檔案： MyClass.cpp
#include <vector>
using std::vector;
struct MyClass::Container : vector<int> {};
MyClass::~MyClass()
{
delete pContainer;
}
MyClass::MyClass() :
pContainer(new Container)
{}
好了，經過小小的努力，使得在 .hpp 中引入 vector 的必要性解除
了。稍微檢討一下得失：
一、本來 vector 物件是配置在 stack 上，變成到 heap 上，效率
上相差不大（實際上配置在哪是要看 MyClass 的用戶），比較麻
煩的是 MyClass 不再適用 C++ 編譯器預設的 memberwise-copy
動作，也就是 copy ctor 和 copy assignment 必須自己實現（如
果需要的話）。
二、好處在哪裏？首先，vector 是 C++ Standard 的東西，它的介
面基本上可以當作不變。此外，直接在 .hpp 內引入 vector 似乎
也沒多慢……。關鍵在於，假如 MyClass 是個被大量引用的模組，
一旦它有任何改變，使用這種方法，就大大降低 vector 被直接曝
光的次數了（畢竟它的原始碼，包含其他引用模組的原始碼也不短）。
三、另一個好處是，可能 MyClass 的設計者後來發現，vector 不太
適當，也許換成 deque 或 list 較好，甚至考慮 multiset 或
multimap 等等（畢竟需求是常常在改變的，而設計考量的周密性
始終有限）。那麼這種設計的優點就充份展現出來了，因為不但
只要改動極少的程式碼（就是把原來繼承 vector 改成繼承其他
容器），更重要的是，整個 MyClass 的介面不變，其他引用到的
模組不必重新再編譯。
四、而且，即使 MyClass 介面的其他部份改變了，但 vector 這種
大量消耗編譯器分析及具現化時間的模組，沒有直接曝光，所有的
動作都只限於 MyClass 模組內部，其他模組不受影響，雖然要重
新編譯（因為 MyClass 介面的其他部份改變了），但速度也會快
得多。
當然，由於標準容器實在是太常用了，這種手法的好處平時並不太
明顯，不過如果儘量依照這種原則，將最常用、以及最耗費編譯時間
的幾個工具模組，採用這種方式製作，當專案的規模擴大時，它所帶
來的各種優勢（主要是編譯依存性的降低，編譯效率的改善），就會
愈來愈明顯。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.120.214.120
... <看更多>