本文聊聊C++中的模板類型推導和auto。兩者其實是一樣的，前者推導T的類型，后者推導auto的類型。本文初創(chuàng)于公司內部博客，更適合于有基礎的同學參考。

模板類型推導

對于模板函數(shù)來說，編譯器需要根據(jù)實際傳入的參數(shù)來推導模板類型T。例如，假設我們有下面這個模板函數(shù)：

template<typename T>
void f(T& param);       // param is a reference

同時聲明了這些變量：

int x = 27;             // x is an int
const int cx = x;       // cx is a const int
const int& rx = x;      // rx is a reference to x as a const int

那么調用模板函數(shù)時，編譯器推導出的模板類型分別為：

f(x);                   // T is int, param's type is int&
f(cx);                  // T is const int, param's type is const int&
f(rx);                  // T is const int, param's type is const int&

可以發(fā)現(xiàn)，同樣是整型變量，帶不帶const、是不是reference，類型推導的結果是不一樣的。回到剛開始聲明的模板函數(shù)，我們聲明了參數(shù)類型為T&，如果聲明為T，或者是T&&，又會得到怎樣的結果呢？我們用表格來總結一下：

是不是有點眼花繚亂？死記硬背是記不住的，我們找一找其中的規(guī)律。

• 一般情況下，param的類型是最完整的類型，繼承了形參中聲明的cr（const和reference）和實參中帶過來的cr。但有兩個特例：
  • 特例一：當形參是通用引用（T&&作為模板參數(shù)時稱為通用引用）時，param根據(jù)具體的實參類型，推導為左值引用或者右值引用。
  • 特例二：當形參不是引用時，實參到形參為值傳遞，去除所有cr修飾符。
• T中是否包含cr修飾符，取決于param的修飾符是否已在形參中聲明過。也就是說，T中修飾符不會與形參中已聲明的修飾符重復。

為什么我們需要知道這些規(guī)則呢？這是因為，有時候需要根據(jù)傳入的param的類型構造與之相關聯(lián)的其它類型的對象。比如我們想要在函數(shù)內部構造一個與param同類型但去除cr修飾符的對象，那么就應該把形參聲明為const T& param，然后聲明T obj這個對象。這是因為上表中第4行表明了，無論實參包含了什么修飾符，無論是左值還是右值，T都是不帶任何修飾符的單純類型。當然，聲明為T param也是可以的，但這種情況下參數(shù)就是值傳遞了。所以說，根據(jù)實際情況選擇合適的模板參數(shù)類型是很重要的。

最后，為了更容易實踐，我們總結出下面三個推薦用法：

• 想要按值傳遞，將模板函數(shù)參數(shù)聲明為T param。
• 想要按引用傳遞，但不考慮右值時，將模板函數(shù)參數(shù)聲明為const T& param。
• 想要按引用傳遞，但要區(qū)分左值和右值時，將模板函數(shù)參數(shù)聲明為T&& param。

auto類型推導

理解了上一節(jié)的模板類型推導后，auto類型推導就很簡單了。除了極個別情況，auto類型推導與模板類型推導是完全一致的。比如，上一節(jié)表格中的四種模板函數(shù)調用都可以寫出對應的auto語句（只寫出對實參x調用的那一列）：

auto& param = x;        // auto is int, param's type is int&
const auto& param = x;  // auto is int, param's type is const int&
auto&& param = x;       // auto is int&, param's type is int&
auto param = x;         // auto is int, param's type is int

decltype

decltype是一個運算符，用來獲取一個變量或表達式的實際類型。之所以需要這個運算符，是因為在某些情況下，特別是模板函數(shù)中，我們事先根本不知道應該創(chuàng)建一個什么類型的變量。舉個簡單的例子，下面這個模板函數(shù)用來獲取任意一個容器對象的第i個元素：

auto get(Container& c, Index i) -> decltype(c[i])
{
    return c[i];
}

函數(shù)聲明用到了C++11中的trailing return type語法，即返回類型后置。該語法支持在原本書寫返回類型的地方用auto占位，然后在參數(shù)列表后面加上“→返回類型”。這里之所以用到了這個語法，是因為c[i]必須在其聲明的位置后面才可以訪問到。

你可能會想，是否能夠進一步簡化呢？讓編譯器自動推導返回值類型不是更方便嗎。正是為此，C++14提供了如下的寫法：

template<typename Container, typename Index>
auto get(Container& c, Index i)
{
    return c[i];
}

返回值直接由c[i]的類型自動推導。但我們不能高興地太早，根據(jù)auto類型推導的規(guī)則，現(xiàn)在這種寫法相當于：

auto element = get(Container& c, Index i);

這是有問題的。這種形式對應于第1節(jié)表格的最后一行，返回值會按值傳遞。如果c[i]的實際類型是引用，函數(shù)返回類型會自動去掉引用這一修飾符，這在有些情況下不是我們想要的結果。我們想要的結果是，函數(shù)返回類型與c[i]完全一致，如果c[i]是引用，那么返回類型也是引用，如果c[i]不是引用，那么返回類型也不是引用。遺憾的是，第1節(jié)表格中提供的四種聲明方式都不能滿足我們的需求，auto&和auto&&會把非引用變成引用，const auto&會添加額外的const，auto會把引用變成非引用。

現(xiàn)在，唯一的方法就是借助decltype，將函數(shù)改寫如下：

template<typename Container, typename Index>
decltype(auto) get(Container& c, Index i)
{
    return c[i];
}

現(xiàn)在，函數(shù)返回類型一定與c[i]的類型完全一致了。但別急，到這里還沒完，因為這個函數(shù)仍有可改進的空間。注意到，我們把Container的參數(shù)設為了引用，這就注定它不能接收右值對象，比如臨時創(chuàng)建的Container對象。另寫一個重載函數(shù)可以解決該問題，但不優(yōu)雅。借助通用引用和完美轉發(fā)可以解決這個問題，請看最終版的代碼：

decltype(auto) get(Container&& c, Index i)
{
    return std::forward<Container>(c)[i];
}

std::forward會根據(jù)實參的實際類型將c轉換為左值引用或右值引用。關于通用引用和完美轉發(fā)，可以參考《右值引用那些事兒》。這里，我們同時給出C++11版本的實現(xiàn)，以供對比：

template<typename Container, typename Index>
auto get(Container&& c, Index i) -> decltype(std::forward<Container>(c)[i])
{
    return std::forward<Container>(c)[i];
}

如何查看類型推導結果？

編程過程中，我們經常需要知道模板類T或者auto的推導結果到底是什么，是否符合我的預期。這里介紹四種方式。

1. 使用IDE的自動提示。像Clion這種IDE，把鼠標放上去就會有自動提示的。但不可盡信，因為IDE內置的語法分析并不總是那么可靠。

2. 讓編譯器告訴我們。編譯器一定是最準的，但讓編譯器輸出T或auto的類型卻并不容易。我們需要手動構造一個編譯錯誤，它才會把錯誤部分的類型打印出來。比如，想要查看x的類型，需要先聲明一個空的模板類

template<typename T>
class TD;               // TD means "Type Displayer"

然后實例化對象

int y = 0;
const int& x = y;
TD<decltype(x)> xType;  // Compiler will report error at this line, which contains x's type

在我的計算機上，輸出的錯誤信息是

error: aggregate 'TD<const int&> xType' has incomplete type and cannot be defined

這樣就可以看到，x的實際類型是const int&。

3. 運行時輸出。這是我們通常最容易想到的方法。C++提供了typeid操作符，用法如下：

std::cout << typeid(x).name() << std::endl;

在我的計算機上，輸出結果為i。

i是typeinfo類中定義的int的簡稱。很顯然，這里的結果是錯誤的，因為x的實際類型是const int&，而typeinfo卻認為它是int。之所以會出現(xiàn)這種情況，是因為x傳入typeid時采用了值傳遞，所有cr修飾符都被丟棄了。所以，typeinfo只適合檢查變量的基礎類型，不能用來查看其完整類型。

4. 使用boost庫中的typeindex。這種方式需要引入第三方庫，但可以保證結果絕對準確，代碼示例如下：

std::cout << boost::typeindex::type_id_with_cvr<decltype(x)>().pretty_name() << std::endl;

type_id_with_cvr中的cvr指的是const、volatile和reference三種修飾符。使用前先#include <boost/type_index.hpp>。在我的計算機上，輸出結果為int const&，完全正確。

這四種用法各有其適用場景，總結一下：

• 最方便快捷：IDE提示和typeid操作符。
• 最準確：編譯器提示和boost::typeindex。

用auto代替顯式類型聲明

auto有顯而易見的優(yōu)點，比如，它可以使你的代碼更簡潔，避免手寫類型出錯等等。不過你可能并不覺得這是多大的優(yōu)點，但看看下面這個例子，就會發(fā)現(xiàn)不用auto的壞處了。

std::unordered_map<std::string, int> m;
// ...
for (const std::pair<std::string, int>& p : m)
{
    // do something with p
}

在range-for循環(huán)中，我們用const std::pair<std::string, int>&類型的變量綁定m中的每個鍵值對，看起來天衣無縫。但事實是，m中的每個鍵值對并非該類型，正確的類型應該是const std::pair<const std::string, int>&，鍵是const類型的。上面的寫法導致創(chuàng)建了臨時變量以及隱式類型轉換，不知不覺中就造成了性能損失。如果使用auto，這種問題就能完全避免。

再來舉一個例子，下面展示了兩種保存lambda對象的方式：

auto my_function1 = [](const std::vector<int>& v1, const std::vector<int>& v2) {return v1.size() + v2.size();};
std::function<std::vector<int>::size_type(const std::vector<int>&, const std::vector<int>&)> my_function2 = [](const std::vector<int>& v1, const std::vector<int>& v2) {return v1.size() + v2.size();};

前者直接保存為lambda對象，后者相當于轉換成了std::function對象后再保存。雖然用的時候并無區(qū)別，但如果我們看一下這兩個對象的大小，就會發(fā)現(xiàn)前者比后者小的多：

std::cout << sizeof(my_function1) << std::endl;     // output: 1
std::cout << sizeof(my_function2) << std::endl;     // output: 32

這是因為，std::function是一個功能完善的標準化類，提供了額外的功能，而lambda表達式生成的對象僅僅包含一個operator()，連數(shù)據(jù)成員都不需要，所以占用空間非常小。因此在這個例子中，auto無論是在簡潔性上，還是在性能上，都完全優(yōu)于std::function。

當auto出錯時，使用static_cast顯式指定類型

最后一節(jié)來說說auto不行的場景。有時候，自動推導出的類型反而不是我們想要的類型，這種情況在invisible proxy這種設計模式中可能遇到。舉個最常見的例子，我們經常用Eigen這個矩陣庫，比如下面的代碼：

Eigen::MatrixXd m1, m2;
// ...
Eigen::MatrixXd m = m1 + m2;

如果把第二句換成

auto m = m1 + m2;

這是會出問題的。因為m1 + m2得到的并不是一個Eigen::MatrixXd類型的對象，而是const CwiseBinaryOp< sum <Scalar>, const Derived, const OtherDerived>類型，見Eigen文檔Eigen::MatrixBase::operator+。Eigen使用了lazy-evaluation技術，只有當把一個表達式最終賦值給另一個Matrix對象時，才會真正計算表達式的值。也就是說，在調用Eigen::Matrix::operator=時，才會真正執(zhí)行加法運算。一旦我們用auto替代了Eigen::MatrixXd，這個表達式就仍然保持其表達式的狀態(tài)，而不進行運算。關于Eigen的內部實現(xiàn)機制，可以參考What happens inside Eigen, on a simple example，保證干貨滿滿。

還有一種情況，如果我們想要進行隱式類型轉換，比如：

float float_number = getDoubleNumber();

這種情況也是無法用auto替代float的。但此處有更好的解決方式。像上面這樣的隱式類型轉換是不推薦的，因為這句代碼沒有體現(xiàn)出開發(fā)者的主觀意愿，不知道開發(fā)者是忘記了等號兩邊類型不一致，還是知道但故意這樣寫。更好的做法是：

auto float_number = static_cast<float>(getDoubleNumber());

這就沒有任何歧義了。