該標準是否對基本類型的移動提供任何保證？

該標準是否對基本數據類型提供任何保證？該標準是否對基本類型的移動提供任何保證？

int i = 42; 
int j = std::move(i); 
// what can we say about i here?

合理的選擇是保持移動的值不變或將其設置爲零？

很顯然，上面的代碼本身沒什麼意義，但是認爲模板。

來源

2014-11-24 Tobias Brüll

未觸動的工作量少，所以我會假設一個合理的實現將表現得好像它只是被複制一樣。但我不知道標準實際上保證了什麼。有趣的問題。 – Cameron 2014-11-24 22:45:46

@Tobias你是什麼意思的「保證」？在你的例子中，'std :: move'只是將類型改爲右值引用，不涉及「物理」移動。如果左側沒有移動構造函數/賦值運算符，則該對象通過其複製構造函數複製（或僅分配給POD）。基本類型肯定沒有移動語義。這是你所問的還是我誤解你的問題？ – vsoftco 2014-11-24 22:48:15

@vsoftco哦，是的。當然...謝謝。 – 2014-11-24 22:51:23

POD並不真正移動，他們複製（或者，他們的複製和移動是相同的操作，因爲在這種情況下沒有什麼可以「移動」） - 請參閱here。

來源

2014-11-24 22:49:09

如果我正確理解了vsoftco（上面）的評論，那麼「移動」只是說「複製」的一種奇特方式，實際上並沒有做任何事情。在這方面，我不明白你的「小調優」言論。你能詳細說明一下嗎？ – 2014-11-24 22:57:55

@TobiasBrüll通過閱讀互聯網上的其他一些例子，我開始相信，在這種情況下，編譯器可能實際上決定使用相同的內存地址來存儲兩個值。但你是對的，那是不正確的。現在更改答案。謝謝！ – 2014-11-24 23:00:38

@martin_pr它可能在 – 2014-11-25 00:14:26

內置=運算符，如a = b使用時，已充分證明長期的閱讀b的價值的行爲，並將其存儲在a。標準中沒有任何內容表明整數賦值會修改賦值RHS。

5.17分配和複合賦值運算符[expr.ass]

...

2在簡單賦值（=），則表達式的值替換的對象稱爲由左操作數。

沒有關於更改任何其他對象的任何值的說法，所以其他對象的值不得更改。

重載自定義operator=實現的行爲可能會有所不同，並且許多標準庫類型實際上會使其行爲不同，但不影響爲該語言的內置=運算符提供的保證。

來源

2014-11-24 22:49:26 hvd

的as if規則下。但是，問題是關於移動語義及其在模板化代碼中的使用（其中std :: move可能在POD上使用）。賦值運算符是相關的，但我相信問題不在於此。此外，我不相信你的答案在一般情況下是正確的 - 例如，std :: auto_ptr並不遵循你的結論（儘管所有的POD都這樣做）。 – 2014-11-24 22:52:54

@martin_pr'std :: move'從來沒有任何類型的副作用。它只是返回它的論點。 – hvd 2014-11-24 22:54:05

@martin_pr至於'auto_ptr'，我特別提到操作符可以重載，重載操作符的行爲可能會有所不同。這個問題詢問基本類型。我回答了基本類型。（要明確，「基本類型」具有特定含義，標準庫類型不一定是基本類型。） – hvd 2014-11-24 22:54:48

該標準是否對基本類型的移動提供任何保證？

回答

相關問題