關於左值到右值的轉換，當需要它？

Question

我一直在網上閱讀很多人，似乎很多人提到了下面的規則（但我在標準中找不到它），

加法運算符+（和所有其他二元運算符）要求兩個操作數都是右值，結果是右值。 等等..

我檢查C++標準，它明確指出（第3.10/2），

每當glvalue出現在 上下文其中prvalue預計， 的glvalue被轉換爲prvalue

（第5/9），

每當glvalue表達似乎 作爲操作者的操作數 預計，該操作數一prvalue， 左值到右值（4.1）， 陣列到指針（4.2），或 函數到指針（4.3）標準 轉換適用於將 表達式轉換爲prvalue。

它使用術語操作數「期望」prvalue。然而，當我看着加法運算，乘法運算符等，僅提及的是，結果是prvalue，但它並沒有說什麼操作數「預期」是什麼。

無論做二元運算符真的認爲操作數是prvalue使得在以下情況下的差異，

int b = 2; 
int a = b + 1; 

若b有望成爲一個prvalue，會有一個左值到右值轉換在這裏，然後它會執行prvalue + prvalue並返回prvalue，結果prvalue分配給左值一個。

但是，如果是一個prvalue b不是必需的，這將是左值+ prvalue，結果是一個prvalue。

我真的想知道在什麼地方標準明確或含蓄地提到，對於不同的運營商 規則？我檢查了所有操作符部分，並且只檢查了幾個操作符，標準明確提到操作數和結果是左值還是右值。對於大多數操作員來說，標準只提到結果，而不是操作數要求。

謝謝。

---

順便說一下，我在標準5.19關於常量表達式發現可能非常非常「含蓄」暗示二元操作需要對操作數左值到右值的轉換。詳情請參考我以前的問題，

mixing use of constexpr and const?

甲條件表達式是一個常數 表達除非它涉及的 下列之一爲潛在 評估子表達式（3.2）。

...

- 左值到右值轉換（4.1） ，除非它被施加到

---- 整型或枚舉類型的glvalue該 是指非-volatile const對象 與前面的初始化， 以恆定表達初始化

感謝閱讀。

Answer 1

所以，這通常是標準中那些推斷和不明確的部分之一;然而，在3.10

[注：一些內置的運營商期望的左值操作數。 [例如：內置的賦值操作符都希望左手操作數是左值。 - 結束示例]其他內置運算符產生rvalues，並且有些期望它們。 [例如：一元和二元運算符需要右值參數併產生右值結果。 - end example]對第5節中每個內置運算符的討論指出它是否期望左值操作數以及它是否產生左值。 - 注完]

通知指定的不良語言「在第5指示是否它期望左值操作數，以及是否它產生一個左值」。

第5章的審查表明，每一個地方的表達需要或返回左值枚舉情況下，然而極少數情況下與右值專門處理列舉，我認爲這是再假定其餘被假定爲右值。

我也懷疑它是很不明確的，因爲從標準的角度來看，如果轉換是由操作員隱式地或顯式地完成的話，這並不是特別重要，無論這種行爲應該是一致的和行爲良好的。

Answer 2

（首先對不起我的英語更正絕對惠康）

的標準說：

§5.7-3二元+運算符的結果是操作數的總和。 [...]

讓我們假設我們有表達e1 + e2，並選擇了+操作是內置於一體，表達良好的，e1和e2是算術類型或鑄件中，以算術類型是可用的，一切都很好，很好，完美！

因此，規則§5.7-3適用。在另一方面，每個操作數是一個表達式：

§5-1[注：[...]表達式是符和操作數，指定計算的序列。表達式可能會導致一個值，並可能導致副作用。 - 注完]

它說的表達可以結果的值，因爲void表情，像delete表達或void功能，但既然我們已經說過e1 + e2是一個完全自定義的表情！ ，我們可以省略動詞「can」，所以我們可以證實：表達式的結果值爲。我的理解是，雖然它沒有被標準規定，但只有它的操作數的值很重要，不管它們的值的類別如何。

我認爲，使用表達式就足以實現內置運算符+（和其他算術運算符），因爲只有值很重要，並且可以通過表達式達到該值。出於這個原因，標準沒有明確界定它們。

所有相同的，這種類型的東西是非常糟糕的結構。例如，當運算符接收到一個作爲操作數的對象而不是直接值（懷疑我目前正在嘗試解決的問題）時，我發現沒有地方指定，如果操作員應該直接取其值來計算操作符，如果該值是評估對象的結果，等等。很明顯，只有價值觀纔是重要的，但是，這些標準對於這些事情的確是一種神祕。