填坑吧，模板君

templatestd::string tostring(const t& x)

然而，有時我們並不總希望所有的型別都以引用的方式傳遞引數，為此只能為每乙個必須要傳值的引數型別寫乙個模板的特化。

顯然，模板庫自己是不可能知道某個模板函式對於哪些型別需要傳引數，哪些需要傳引用，除非模板庫的使用者和開發者是同乙個團隊。即便可以知道，書寫大量型別的特化顯然是吃力不討好的事。

問題總是要解決的，於是，乙個最笨的方案被提出來了：完全可以寫兩套模板呀（提出這種方案的人大概忘了為什麼要使用模板了吧）。典型的例子就是上篇部落格中提到的tie函式，與他極為類似的有個make_tuple函式，下面是它們倆的實現：

make_tuple(_elements... __args)

templateinline tuple<_elements&...>

tie(_elements&... __args)

不過我始終覺得寫兩套介面終究還是違背c++模板的初衷的，所以這樣的設計或許更好一些：

class isref {};
templateinline tr1::tuple<_elements...>
make_tuple(_elements... __args)
templateinline tr1::tuple<_elements&...>
make_tuple(isref isref, _elements&... __args)

這樣一來給人的感覺是一套介面了，但是那個多出的乙個引數isref還是十分刺眼，彷彿相當於make_tuple2一樣，似乎仍然是換湯不換藥。更重要的是，大部分情況下需要部分引數傳引用，部分傳值，到目前為止都是一刀切的方案。於是，大神說了，誰挖的坑誰來填。改函式名和該引數數量這種過載方式都不夠友好，最終還是模板提供了更有效的方法。

其實stl中的make_tuple就支援傳引用和傳值的引數。不過直接c++的形式還是不行的，得借助於它提供的乙個包裝類。用法如下：

int main()

上面的程式輸出結果為：1.

ref(_tp& __t)

_m_data(__inref._m_data)

operator _tp&() const

_tp&

get() const

};它的基類是用於支援各類函式指標的。並且上面的實現中已經刪去了函式指標有關的實現。這個類只有乙個成員變數，儲存了被引用的變數的指標。定義了get方法用於得到引用值。即ref本質上傳遞的是物件的指標，但是包裝類使其對外的介面與引用無異。

填坑吧，模板君

Jenkins填坑之郵件模板分享

MySQL坑與填坑

模板篇伸展樹Splay Tree（此坑待填）

填坑吧，模板君

Jenkins填坑之郵件模板分享

MySQL坑與填坑

模板篇 伸展樹Splay Tree（此坑待填）

相關推薦

模板篇伸展樹Splay Tree（此坑待填）