前幾天，博主看了一篇文章抨擊C++的泛型會導(dǎo)致生成的可執(zhí)行文件代碼臃腫。

博主從事C++軟件開發(fā)多年，由于之前的開發(fā)環(huán)境都是資源充足的服務(wù)器，不用考慮磁盤空間的問題。最近打算在智能家居主機的嵌入式平臺上使用C++進行開發(fā)。FLASH存儲空間有限，這是必須要考慮的因素，一定要重視。

如下定義兩個list，元素類型不同：

list<int> l1; 
list<string> l2; 

如果是用C語來做應(yīng)該怎么辦？它會對應(yīng)list<int>寫一套代碼，再對list<string>寫一套。每套都有相同的成員函數(shù)，只是變量類型各自不同罷了。

下面是list<int>的C語言實現(xiàn)方式：

//! code-1 
struct list_int_item { 
    int value; 
    struct list_int_item *next; 
}; 
 
struct list_int { 
    struct list_int_item *head; 
    size_t size; 
}; 
 
void list_int_insert(struct list_int *p, int value); 
int  list_int_sort(struct list_int *p); 
bool list_int_empty(struct list_int *p); 
... 

下面是list<string>的C語言實現(xiàn)方式：

//! code-2 
struct list_string_item { 
    string value; 
    struct list_string_item *next; 
}; 
 
struct list_string { 
    struct list_string_item *head; 
    size_t size; 
}; 
 
void list_string_insert(struct list_int *p, string value); 
int  list_string_sort(struct list_int *p); 
bool list_string_empty(struct list_int *p); 
... 

兩者之間就是類型的差別。所以很多時間，在C語言中我們就用宏來替代它的類型，如下：

//! code-3 
#define LIST_DECLARE(TYPE) \ 
    struct list_##TYPE##_item { \ 
        TYPE## value; \ 
        struct list_##TYPE##_item *next; \ 
    }; \ 
    \ 
    struct list_##TYPE { \ 
        struct list_##TYPE##_item *head; \ 
        size_t size; \ 
    }; \ 
    \ 
    void list_##TYPE##_insert(struct list_##TYPE *p, ##TYPE## value); \ 
    int  list_##TYPE##_sort(struct list_##TYPE *p); \ 
    bool list_##TYPE##_empty(struct list_##TYPE *p); \ 
    ... 

然后在頭文件中是這樣定義list<double>的：

//! code-4 
 
LIST_DECLARE(double) 

所以，泛型產(chǎn)生冗余代碼是無法避免的，至少用C來做這樣的泛型也是無法避免的。

既然無法避免的，那就看看怎么盡可能以避免上述的問題。在《Effective C++》中有一章節(jié)專門提到：不要在模板中使用不必要的參數(shù)。因為每一個不同的參數(shù)編譯器都會為之生成一套相應(yīng)的代碼。

如果代碼中只有一種數(shù)據(jù)類型，就算用該類型定義了多個變量，編譯器是不是只會生成一套相關(guān)的代碼？（應(yīng)該是這樣的）。

寫個例子對比一下：（省略不必要的代碼）

test1.cpp，里面只有map<int, string>，但定義了m1, m2, m3。

//! code-5 
    map<int, string> m1; 
    map<int, string> m2; 
    map<int, string> m3; 
 
    m1.insert(std::make_pair(1, "hello")); 
    m2.insert(std::make_pair(1, "hi")); 
    m3.insert(std::make_pair(1, "lichunjun")); 

test2.cpp，與test1.cpp相比，里面有三個類型：

//! code-6 
    map<int, string> m1; 
    map<int, double> m2; 
    map<int, int> m3; 
 
    m1.insert(std::make_pair(1, "hello")); 
    m2.insert(std::make_pair(1, 1.2)); 
    m3.insert(std::make_pair(1, 44)); 

結(jié)果，編譯出來的可執(zhí)行文件大小比較：

[hevake_lcj@Hevake tmp]$ ll test1 test2 
-rwxrwxr-x. 1 18784 Mar 19 22:01 test1 
-rwxrwxr-x. 1 35184 Mar 19 22:03 test2 

test2比test1大一倍，原因不用多說。

還有一個問題：指針是不是被認為是一個類型？

上面的list<int>與list<string>不能共用同一套代碼，根據(jù)的原因是因為int與string這兩種類型在空間大小與賦值的方式上都是不同的。所以，必須生成兩套代碼來實現(xiàn)。

而指針，不管是什么指針，它們都是一樣的。我們可以用void*代表所有的指針類型。

于是我們將上面的代碼改改，再測試一下：

//! code-7 
    map<int, string*> m1; 
    map<int, string*> m2; 
    map<int, string*> m3; 
 
    m1.insert(std::make_pair(1, new string("hello"))); 
    m2.insert(std::make_pair(1, new string("hi"))); 
    m3.insert(std::make_pair(1, new string("lichunjun"))); 

與

//! code-8 
    map<int, string*> m1; 
    map<int, double*> m2; 
    map<int, int*> m3; 
 
    m1.insert(std::make_pair(1, new string("hello"))); 
    m2.insert(std::make_pair(1, new double(1.2))); 
    m3.insert(std::make_pair(1, new int(44))); 

結(jié)果是這樣的：

-rwxrwxr-x. 1 18736 Mar 19 23:05 test1 
-rwxrwxr-x. 1 35136 Mar 19 23:05 test2 

預(yù)期的結(jié)果test1與test2相差不多，但從結(jié)果上看并沒有什么優(yōu)化，結(jié)果有點令人失望～

思考：C++有沒有什么參數(shù)可以優(yōu)化這個？

如果沒有，為了節(jié)省空間，我們只能將所有的指針統(tǒng)一定義成void*類型了，在使用時再強制轉(zhuǎn)換。

//! code-9 
    map<int, void*> m1; 
    map<int, void*> m2; 
    map<int, void*> m3; 
 
    m1.insert(std::make_pair(1, new string("hello"))); 
    m2.insert(std::make_pair(1, new double(1.2))); 
    m3.insert(std::make_pair(1, new int(44))); 
 
    cout << *static_cast<string*>(m1[1]) << endl; 
    cout << *static_cast<double*>(m2[1]) << endl; 
    cout << *static_cast<int*>(m3[1]) << endl; 

如上代碼是將code-8的基礎(chǔ)上，將所有的指定都定義成了void*，在使用的時候用static_cast進行強制轉(zhuǎn)換成對應(yīng)的指針類型。

如此得到的代碼大小與code-7的比較，只多了16個字節(jié)。

但這種做法是很不可取的，必須用void*指針之后，編譯器不再對類型進行檢查，很容易把類型搞混淆。

***還是編譯器支持指針泛型的優(yōu)化吧！