2009年4月份，我們的TTCN3新執行器大體功能已經完成了，於是找了幾個專案來試點應用。

應用效果不太理想，特別是對於5萬行以上的指令碼工程，且包括大asn檔案的情況。

新執行器轉換出來的C++程式碼量很大，特別是由於asn型別很多，導致hpp檔案程式碼量大的編譯速度下降嚴重問題。

當時的資料大概是這樣的，大asn檔案存在5千多個不同的型別（約5萬行），包括簡單和複雜型別，

平均每個型別轉換後的hpp程式碼量，約20行，合計超過1萬行的hpp檔案，全編譯一次約30分鐘時間（30萬代碼量），使用者不接受。

我們曾經考慮過windows的pch方法來加快編譯速度，但不可行，因為使用者型別是可變的。

最後，只能從轉換的hpp程式碼入手，看看那些可以省略的。

當時一個型別包括的成員函式大概如下：

1、預設建構函式

2、引數為基類的建構函式

3、拷貝建構函式

4、賦值操作函式

5、引數為基類的賦值操作函式

6、靜態clone函式

7、解構函式

從上面的成員函式來看，已經很精簡的了，用於比較操作的函式已經直接在基類中實現。

但我們還是發現了一個問題，就是建構函式和賦值函式使用過多，

這樣做的原因，是為了簡化轉換器的邏輯，譬如：

var  myType  t1;

var  myType  t2  :=  t1;  //這裡轉換後的C++程式碼可以通過拷貝建構函式實現

t2  :=  t1;  //這裡轉換後的C++程式碼可以通過賦值操作函式實現

正因為C++支援操作符號過載，所以可以很方便的簡化轉換器的處理邏輯。

但也是因為這個問題，導致建構函式和賦值操作函式濫用，hpp檔案過大，編譯速度下降。

於是，我們重複問自己，這真的有必要嘛？

當然沒有必要，其實所有這些都可以簡單通過使用一個虛擬函式實現，如

virtual bool assignValue（const& baseType）;

簡單來說就是，轉換器需要使用assignValue代替=符號，於是拷貝構造和賦值操作函式都不需要了。

由於assignValue的引數是基類引用，所以一個函式就可以搞定多種情況。

就這樣，原來一個類需要20行的hpp程式碼量，現在下降到10行，編譯效能提升2倍（這也驗證了hpp檔案對編譯速度影響很大）。

這個方案將大工程的編譯速度從30分鐘下降到10分鐘，

但後來我們找到一個更根本的方法，從而有從10分鐘下降到3分鐘，後續再說。