※ 引述《WangDaMing (王大明)》之銘言：
: 開發平台(Platform): (Ex: Win10, Linux, ...)
: Linux
: 編譯器(Ex: GCC, clang, VC++...)+目標環境(跟開發平台不同的話需列出)
: GCC
: 最近看到一個例子不太懂這是c++的甚麼機制讓他產生暫時物件的
: #include <iostream>
: #include <string>
: using namespace std;
: int main(){
: pair<const string,int> data = {"123",5};
: const pair<string,int> &ref = data;
: }
: 我看文章說因為data的first是const可是ref的first沒有const但是編譯器
: 不會讓他編譯錯誤會產生暫時物件.
: 1.可是這邊我就不懂了,是甚麼機制讓他產生暫時物件的?有這機制的名稱嗎??
: 還有為何不讓他編譯錯誤要幫他產生暫時物件??
: 2.這種暫時物件新手蠻容易犯錯的,
: 有比較好的方式可以幫助我們確認是否產生暫時物件嗎??
: 我知道書上推薦用auto不過如果先不考慮auto有甚麼方法確認嗎??
: 感謝各位
: ※ 編輯: WangDaMing (111.248.244.154 臺灣), 01/10/2022 22:18:42
Well,我不知道你看的是哪篇文章
不過"編譯器不會讓他編譯錯誤"是一個不算錯但容易誤導的講法XD
這段程式碼好玩的地方在於，你把下面那行的const拿掉，他就編不過了
但是如果你把const跟reference都拿掉，突然又可以編過了:
https://godbolt.org/z/en8rWP511
所以到底是編的過還是編不過?碰到這種情況該怎麼判斷?
實際上你應該從最簡單的，也就是沒有const，也沒有reference的情況開始驗證:
pair<string,int> ref = data;
這樣一段程式碼編譯器判斷是OK的，代表有兩種可能性:
(1).pair<const string,int>在編譯器的認知中，跟pair<string,int>為同型態
(2).pair<const string,int>跟pair<string,int>不同型態，
但pair有提供轉換的constructor，然後編譯器幫你做implicit conversion
如果加了reference就編不過去的話，實際上(2).是比較有可能的
因為reference基本上是要求跟指到的對象type要完全一致(或者是子類)
但這個case是template的parameter多帶了一個const，
到底會不會被判定成不一樣可能會讓對template不熟的人，比較疑惑一點
所以這邊就需要寫code做一點驗證，假設(2).是對的
那理論上我們寫一個很類似pair的template出來，
但不提供轉換的constructor，這時候編譯器就會報錯:
https://godbolt.org/z/8f95rrTdG
如果你對type_traits有一點認識，其實也可以用is_same去做檢驗:
https://godbolt.org/z/a8ahYnT49
不論是哪一個都可以看出來，這兩個型態應該是認定為不一樣的
所以之所以用std::pair可以過，不是什麼"編譯器不會讓他編譯錯誤"
而是std::pair主動去給出constructor，把有cv qualifier的情況再涵蓋近來
這個std::pair的constructor寫法類似下面這樣
不過為了閱讀方便起見沒寫到很嚴謹，參考就好:
https://godbolt.org/z/GaEsMWqqf
了解了這個基本事實後，我們再把const跟reference加回去:
1.pair<string,int> & ref = data;
不能過，因為reference要求相當嚴格的型態一致
2.const pair<string,int> & ref = data;
可以過，但是為什麼可以過?
這是這段程式碼第二個tricky的地方，因為const reference允許隱式轉換與右值
關於const reference接了右值之後會做什麼事，Sutter大神有寫過文章可以參考:
https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/
版上應該也有講解過這個性質的文章，可以往前翻挖一挖寶藏。
正常來說右值的life cycle是定義到使用他的expression結束時消滅(呼叫destructor)
但透過const reference的綁定，可以將右值的生命週期延續到reference消滅為止
在C++11之前因為沒有rvalue reference，
有時候會用const reference這個性質讓右值留久一點做一些方便的應用。
C++11以後一般就是用rvalue reference做這件事了
不過為了相容性，const reference還是保留了接右值的能力
const reference由於有const的承諾
本身在型態上的要求並沒有non-const reference如此嚴格
non-const reference之所以要有嚴格的型態限制
其中的一個原因就是你有可能會用這個換過型態的reference去改寫原變數的值
但const reference限定只讀，這件事反而不會發生
所以const reference允許你去做隱式轉換:
int x = 3;
const long & y = x; //implicit conversion from int to long
但是const reference實際上不是某個真正的instance，他只是個包過的指標而已
所以這裡就會有一個問題產生，也就是這個指標到底該指到什麼東西?
應該指到x嗎?但指到x是很危險的一件事，以x64的情況來說
因為x只有4個byte，long則有8個byte，就算y的功能只是read value
你也很有可能因為超界存取導致y讀到一個很奇怪的值，
所以這裡他就必須要生一個真正的long出來:
int x = 3;
long temp = long(x);//你沒有寫，但compiler會幫你補
const long &y = temp;
這是為什麼在隱式轉換給const reference之後，會有一個"暫存值"的原因
如果上面這一大坨有看懂的話，要回答你的問題就很簡單了:
1.之所以會有暫存物件，是因為你用了const reference
但就算是const reference，沒有辦法隱式轉換的型態編譯器也是會擋的
這個例子會成功是因為，
std::pair有提供在模板參數多cv qualifier的場合也能建構的constructor
導致assign給const reference時觸發隱式轉換
(確切的說，std::pair的constructor定的抽象非常強，
不單是加減cv qualifier的場合，只要可以被轉換成該型態就可以丟進constructor
原PO的第一行其實就已經在用這個強抽象的好處了)
2.這個例子的觸發條件有三個:
(a).const reference
(b).可隱式轉換的type跟constructor
(c).assign給const reference的expression其type必須觸發隱式轉換
這裡面最不可能發生的事情應該是(c)，
因為99%的情況你會給const reference的值應該是要跟const reference型態一致的
所以(c)發生時比較大的可能應該是寫錯型態了
如果是要避免這個問題的話，可以用type alias去弄一個簡單好記的alias來用:
https://godbolt.org/z/KcW9YEcbo
或是用std::reference_wrapper跟std::cref去避免隱式轉換發生:
https://godbolt.org/z/vrb5TbefW
大概是這樣，有錯還請版友不吝指正。