現代c++模板超程式設計:遍歷tuple
阿新 • • 發佈:2021-03-15
tuple是c++11新增的資料結構,通過tuple我們可以方便地把各種不同型別的資料組合在一起。有了這樣的資料結構我們就可以輕鬆模擬多值返回等技巧了。
tuple和其他的容器不同,標準庫沒有提供適用於tuple的迭代器,也沒有提供tuple型別的迭代介面。所以當我們想要遍歷tuple的時候只能自己動手了。
所以這篇文章我們會實現一個簡單的介面用來遍歷各種tuple,順便一窺現代c++中的模板超程式設計。
void for_each(Iterator first, Iterator last, UnaryFunction f)`,其中`UnaryFunction`的函式簽名是`void fun(const Type &a)`。
通過`for_each`我們可以順序遍歷容器中的每一項資料,我們的`for_each_tuple`也將實現類似的功能——順序遍歷tuple的每一項元素。
不過前面已經提到了,tuple是沒有迭代器的,因此我們的函式得改個樣子:`template void for_each_tuple(const Tuple &, Functor &&)`。因為不能使用迭代器,所以我們傳了tuple的引用進函式。
當然,c++17裡tuple是constexpr型別,所以你還可以給我們的`for_each`加上constexpr。
函式內部要做的事其實也很簡單,就是對每一項元素呼叫f即可,在這裡我們不考慮其他一些細節,我們的介面形式上應該是這樣子的(虛擬碼):
```c++
template
constexpr void for_each_tuple(const Tuple &t, Functor &&f)
{
for element in t {
f(t);
}
}
```
## 實現介面
介面設計好了,下面我們就該實現`for element in t`的部分了。
接下來我會介紹三種實現遍歷tuple的方法,以及一種存在缺陷的方法,首先我們從最原始的方案開始。
### 初步嘗試
距離c++11釋出已經快整整十年了,想必大家也習慣於書寫c++11的程式碼了。不過讓我們把時間倒流回c++11前的時代,那時候既沒有constexpr,也沒有變長模板引數,相當的原始而蠻荒。
那麼問題來了,那時候有tuple嗎?當然有,boost裡的tuple的歷史在c++11前就已經開始了。
其中的祕訣就在於模板遞迴,這是一種經典的超程式設計手段,解鈴還須繫鈴人,我們的foreach也需要藉助這種技術。
現在我們來看一下不使用編譯期計算和變長模板引數的原始方案:
```c++
template
void for_each_tuple_impl(Tuple &&t, Functor &&f)
{
if (Index >= std::tuple_size>::value) {
return;
} else {
f(std::get(t));
for_each_tuple_impl(std::forward(t), std::forward(f));
}
}
template
void for_each_tuple(Tuple &&t, Functor &&f)
{
for_each_tuple_impl(std::forward(t), std::forward(f));
}
```
我們用`std::remove_reference_t`來把Tuple從引用型別轉化為被引用的tuple的型別,原因是模板函式的右值引用引數會自動根據引用摺疊的規則轉換為左值引用或者右值引用,而我們不能從引用型別呼叫`std::tuple_size`獲取tuple的長度。
整體的思路其實很簡單,我們從0開始,每遍歷處理完一項就讓index+1,然後遞迴呼叫impl。如果了最後一個元素+1的位置,函式就返回。這樣遍歷就結束了。
注意f上的`std::forward`,我們用右值引用的目的是接受包括lambda在內的所有可呼叫物件,這些物件可以是一個lambda字面量,可以是一個具名的儲存了lambda的變數,還以可以是函式指標或者任何過載了`template void operator()(const T&)`運算子的類的例項。所以我們很難假設這麼廣範圍內的可呼叫物件都是可以被複制的,所以保險起見我們使用了模板的右值引引數來將不可以複製的內容用右值引用捕獲。當然因為移動語義會產生副作用,這點使用者得自己負擔,而我們也不得不對f使用`std::forward`進行完美轉發。不過這樣好處也不是沒有,至少我們省去了很多不必要的複製。
然而當你滿心歡喜地準備嘗試執行自己傑作的時候,編譯器給你澆了一頭冷水:
```text
...
/usr/include/c++/10.2.0/tuple:1259:12: fatal error: template instantiation depth exceeds maximum of 900 (use '-ftemplate-depth=' to increase the maximum)
1259 | struct tuple_element<__i, tuple<_Head, _Tail...> >
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
報了一大堆錯,甚至超過了螢幕的最大滾動高度(我設定的是10000行)。發生了什麼呢?
稍微翻翻報錯資訊,我們發現了實際上是模板遞迴超過了允許的最大深度。可是我們不是已經給出了退出遞迴的條件了嗎?
讓我再來看看impl的程式碼:
```c++
template
void for_each_tuple_impl(Tuple &&t, Functor &&f)
{
if (Index >= std::tuple_size>::value) {
return;
} else {
f(std::get(t));
// 注意下面這行
for_each_tuple_impl(std::forward(t), std::forward(f));
}
}
```
編譯器在編譯函式的時候是需要把所有條件分支都編譯的,__所以即使是在函式模板的例項達到退出遞迴的條件,else分支仍然會被編譯__,而在這個分支裡模板會被不斷遞迴例項化,最終超過允許的最大遞迴深度。
這裡就引出了模板遞迴的一個重要規則:**我們應該用模板特化或是函式過載來實現遞迴的終止條件**
然而在這裡我們既不是模板的特化也沒有呼叫過載函式。
如果想利用函式過載的話並不現實,因為遞迴函式呼叫的形式是相同的,無法針對tuple的最後一個元素進行特殊處理。
而函式模板不支援部分特化,所以我們也很難實現一個針對tuple結尾的特化版本。
那怎麼辦呢?
### 通用的古典實現
既然函式模板不能滿足要求,我們使用類模板不就行了。只要過載了`operator()`,使用起來也沒多少區別。
所以一個真正通用的古典實現可以寫出下面這樣:
```c++
template
struct classic_for_each_tuple_helper
{
constexpr void operator()(const Tuple &t, Functor &&f) const
{
f(std::get(t));
classic_for_each_tuple_helper{}(t, std::forward(f));
}
};
```
我們首先實現了主模板,其中Start和End是tuple開始和結束的索引。每處理一個元素,我們就讓Start加上1。
你可以想一想這裡遞迴的停止條件是什麼。
我們每次給Start遞增1,那麼最後我們的Start一定會等於甚至超過End。沒錯,這就是我們的停止條件:
```c++
template
struct classic_for_each_tuple_helper
{
constexpr void operator()(const Tuple &t, Functor &&f) const
{
f(std::get(t));
}
};
```
我們沒辦法在模板引數列表裡判斷相等,那麼最好的解決辦法就是特化出Start和End都一樣的特殊情況,這時候用一樣的值End同時填入主模板的Start和End就行了。
特化的處理也很簡單,我們直接把遞迴的語句刪了就可以了。
想要使用這個幫助模板還需要一點程式碼,因為我可不想每次手動指定一大長串的tuple型別引數。
正好,利用函式模板我們可以自動進行型別推導:
```c++
template
constexpr void classic_for_each_tuple(const Tuple &t, Functor &&f)
{
classic_for_each_tuple_helper - 1>{}(t, std::forward(f));
}
```
這樣我們就可以書寫如下的程式碼了:
```c++
classic_for_each_tuple(std::make_tuple(1, 2, 3, "hello", "world", 3.1415, 2.7183),
[](const auto &element) { /* work */ });
```
即使是`make_tuple`生成的臨時物件,我們也可以自動推匯出它的型別,所有粗活累活編譯器都幫我們代勞了。
不過凡事總是有代價的,有得必有失。表面上我們實現了簡單而漂亮的介面,但代價實際上是被轉移到了底層:
```bash
$ nm a.out | grep classic_for_each_tuple_helper
00000000000031d6 t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm0ELm6EEclERKS3_OS7_
00000000000034f0 t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm1ELm6EEclERKS3_OS7_
00000000000036ca t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm2ELm6EEclERKS3_OS7_
0000000000003946 t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm3ELm6EEclERKS3_OS7_
0000000000003a66 t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm4ELm6EEclERKS3_OS7_
0000000000003b94 t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm5ELm6EEclERKS3_OS7_
0000000000003c0e t _ZNK29classic_for_each_tuple_helperISt5tupleIJiiiPKcS2_ddEEZ4mainEUlRKT_E2_Lm6ELm6EEclERKS3_OS7_
```
我們的tuple有6個元素,所以我們生成了6個helper的例項。過多的模板例項會導致程式碼膨脹。
模板遞迴的另一個缺點是遞迴的最大深度有限制,在g++10.2上這個限制是900,也就是說超過900個元素的tuple我們是無法處理的,除非用編譯器的命令列選項更改這一限制。不過通常也沒人會寫出有900多個元素的tuple。
還有一個需要考慮的情況,當我們傳遞了一個空的tuple進去會發生什麼呢?
```c++
classic_for_each_tuple(std::tuple<>{},
[](const auto &element) { /* work */ });
```
我們會得到一個編譯錯誤,而我們所期望的是foreach什麼也不做。問題發生在`std::tuple_size_v - 1`,當tuple為空時size為0,而對無符號數的0減去1會導致迴環,從而導致get使用的索引的範圍十分巨大,超過了模板遞迴深度限制;而更致命的是get一個無效的索引(tuple為空,任何索引都無效)是被`static_assert`斷言的編譯期錯誤,並且往往會產生一大長串錯誤資訊導致debug困難。
不過別擔心,這是個小問題,解決起來也不麻煩,還記得我們的模板超程式設計技巧嗎?用過載或特化表示邊界條件:
```c++
template
constexpr void classic_for_each_tuple(const std::tuple<> &, Functor &&)
{
// 什麼也不做
}
```
如此一來空的tuple也不會導致問題了。
雖然有些缺點,還需要工具類模板來實現遍歷,但這是舊時代的c++實現`for element in t`的唯一選擇。
### 使用編譯期條件分支
好訊息是現在是現代c++的天下了,我們可以簡化一下程式碼。
比如使用c++17提供的編譯期間計算的條件分支。一般形式如下:
```c++
if constexpr (編譯期常量表達式) {
work 1
} else {
work 2
}
```
`constexpr if`最大的威力在於如果條件表示式為真,那麼else裡的語句根本不會被編譯,反之亦然。當然這得是在模板裡,否則else分支的程式碼仍然會被編譯器檢查程式碼的語法正確性。
沒錯,我們在最開始遇到的問題就是if和else裡的語句都會被編譯,導致了模板的無限遞迴,現在我們可以用`constexpr if`解決問題了:
```c++
template
constexpr void for_each_tuple_impl(Tuple &&t, Functor &&f)
{
if constexpr (Index >= std::tuple_size>::value) {
return;
} else {
f(std::get(t));
for_each_tuple_impl(std::forward(t), std::forward(f));
}
}
template
constexpr void for_each_tuple(Tuple &&t, Functor &&f)
{
for_each_tuple_impl(std::forward(t), std::forward(f));
}
```
這次當遍歷完最後一個元素後函式會觸發退出遞迴的條件,if constexpr會幫我們終止模板的遞迴。問題被幹淨利落地解決了。
對於空tuple這個方案是如何處理的呢?答案是tuple為空的時候直接達到了impl的退出條件,所以是安全的noop。
雖然程式碼被進一步簡化了,但是模板遞迴的兩大問題依舊存在。
### 變長模板引數——錯誤的解法
現代c++有許多簡化模板超程式設計的利器。如果說前面的`constexpr if`是編譯期計算和模板不沾邊,那下面要介紹的變長模板引數可就是如假包換的模板技巧了。
顧名思義,變長模板引數可以讓我們在模板引數上指定任意數量的型別/非型別引數:
```c++
template
class tuple;
```
上面的就是c++11中新增的tuple的定義,通過變長模板引數使得tuple支援了任意多的型別不同的元素。
想要處理變長模板引數,在c++17之前還是得靠模板遞迴。所以我們是不是可以用變長模板引數獲取tuple裡每一個元素的型別呢?正好get也可以根據元素的型別來獲取相應的資料。
於是新的實現產生了:
```c++
template
constexpr void for_each_tuple2_impl(const Tuple& t, Functor &&f)
{
f(std::get(t));
for_each_tuple2_impl(t, std::forward(f));
}
template
constexpr void for_each_tuple2_impl(const Tuple&, Functor &&)
{
return;
}
template
constexpr void for_each_tuple2(const std::tuple &t, Functor &&f)
{
for_each_tuple2_impl, Functor, Ts...>(t, std::forward(f));
}
```
程式碼有些複雜,我會逐步講解。
首先我們有兩個`for_each_tuple2_impl`,不過別緊張,因為模板形參不同,所以這是兩個不同的模板(函式模板沒有部分特化)。又因為變長引數的實引數量可以為0,為了例項化的時候不會產生歧義,只能讓第二個`for_each_tuple2_impl`不接受任何額外的模板引數。
接著我們看到`for_each_tuple2`,它的作用很簡單,通過引數上的`std::tuple`自動推匯出tuple元素的所有型別,然後存放在Ts裡。習慣上我們給變長引數包的名字是以s結尾的,象徵引數包裡可能有不止一個型別引數。
接下來才是重頭戲。當我們這樣呼叫`for_each_tuple2_impl, Functor, Ts...>`時,實際上會展開成`for_each_tuple2_impl, Functor, Type1, Type2, ..., TypeN.>`。
對應到我們的`template `, First就會是Type1,而其他剩下來的型別又會被收集到`for_each_tuple2_impl`的Ts裡,這樣我們就分離出了第一次個tuple裡的元素。
然後我們使用`std::get(t)`獲取到這個元素,然後遞迴重複上述步驟。
Ts的第一個引數會被逐個分離,最後一直到Ts和First都為空,這是遞迴就該結束了,所以我們寫出了第二個`for_each_tuple2_impl`模板來處理這一情況。
因為tuple的型別引數列表的順序和其中包含元素是對應的,所以我們可以實現遍歷。
到目前為止我們的for_each工作得很好,然而當我們傳入了`std::make_tuple(1,2,3)`,編譯器又一次爆炸了。
好奇的你一定又在思考為什麼了。不過這回你應該很快就有了頭緒,`tuple`,存在一樣的型別引數,這時候`std::get`會不會不知道該獲取的是哪個元素呢?
你猜對了,get的文件裡是這麼說的`Fails to compile unless the tuple has exactly one element of that type.`,意思是當某個型別A出現了不止一次時,使用`get`會導致編譯出錯。
因此這個方案是有重大缺陷的,我們不能保證tuple裡總是不同型別的資料。因此這條路走到死衚衕裡了。
### 摺疊表示式——使用變長模板引數的正確解法
彆氣餒,嘗試失敗也是模板超程式設計的樂趣之一。更何況現代c++裡有相當多的實用工具可以加以利用,比如`integer_sequence`和摺疊表示式。
摺疊表示式用於按照給定的模式展開變長模板引數包,而`integer_sequence`則可以用來包含0-N的整數型別非型別模板引數,在我上一篇介紹[模板超程式設計的文章](https://www.cnblogs.com/apocelipes/p/11289840.html)裡有介紹,這裡不再贅述。
使用`integer_sequence`可以構建一個包含所有tuple元素索引的編譯期整數常量序列,配合摺疊表示式可以把這些索引展開利用,這樣正好可以讓get用上每一個索引:
```c++
template
constexpr void for_each_tuple3_impl(const Tuple &t, Functor &&f, std::index_sequence)
{
// 展開成(f(std::get<0>(t)),f(std::get<1>(t)),...)
(f(std::get(t)), ...);
}
template
constexpr void for_each_tuple3(const Tuple &t, Functor &&f)
{
// std::make_index_sequence>產生一個index_sequence<0,1,2,..,N>
for_each_tuple3_impl(t, std::forward(f), std::make_index_sequence>());
}
```
這次不再是模板遞迴了,我們生成了所有元素的索引,然後教編譯器硬編碼了所有的get操作,形式上不太像但確確實實完成了遍歷操作。
當然老問題是少不了要問的,tuple為空的時候這個方案能正常工作嗎?
答案是肯定的,標準規定了`std::make_index_sequence<0>`會生成一個空的序列,而逗號運算子的一元摺疊表示式對於空的引數包會安全地返回void,所以在傳入一個空tuple時我們的函式是noop的。
這種方案簡單粗暴,同時也是三種方法中最直觀的。
而且這個方案不會產生一大堆的模板例項,生成的二進位制檔案也是清爽乾淨的。同時因為不是遞迴,也不會受到遞迴深度限制的影響。
這就是現代c++在模板超程式設計上的威力。
### 總結
我們一共實現了三種遍歷tuple的方法,從原始到現代,從複雜到簡單。
同時我們還踩掉了一些坑,在今後的開發中只要留意類似的問題也能及時避免了。
當然,我寫的方案仍有很大的提升空間,你可以自己進行嘗試改進。
不過我最想說的還是現代c++真的極大簡化了模板超程式設計,把模板超程式設計從一個複雜抽象的黑魔法變成了直觀易於理解的開發技巧,應該有更多的人來體驗使用現代c++的樂趣,c++已經脫胎換
## 介面設計 為什麼要遍歷tuple呢?通常我們確實不需要逐個遍歷tuple的資料,通過使用get取出特定位置的元素就滿足大部分的應用需求了。 但偶爾我們也會想要把某一個泛型演算法應用到tuple的每一項成員上,雖然不多見但也確實有需求的場景存在。因此如何實現對tuple的遍歷就被擺上了議程。 然而遺憾的是get需要的索引只能是編譯期常量,這導致我們無法依賴現有的迴圈語句去實現索引的遞增,因此只有兩條路可供選擇:硬編碼每一項索引和模板超程式設計。我是個不喜歡硬編碼的人,所以我選擇了後者。 把STL裡的通用容器演算法實現一遍工程量太大了,而且很明顯一篇文章也講不完。我決定實現標準庫裡的`for_each`,正好也契合今天的主題——遍歷tuple。 標準庫的`for_each`是這樣的`template本文索引
- 介面設計
- 實現介面
- 初步嘗試
- 通用的古典實現
- 使用編譯期條件分支
- 變長模板引數——錯誤的解法
- 摺疊表示式——使用變長模板引數的正確解法
- 總結