C++爲什麼在Move構造函數和Move Assignment Operators的上下文中需要noexcept來啓用優化？

Question

考慮下面的類，具有移動構造函數和移動賦值操作符：

class my_class 
{ 

    protected: 

    double *my_data; 
    uint64_t my_data_length; 
} 

my_class(my_class&& other) noexcept : my_data_length{other.my_data_length}, my_data{other.my_data} 
{ 
    // Steal the data 
    other.my_data = nullptr; 
    other.my_data_length = 0; 
} 

const my_class& operator=(my_class&& other) noexcept 
{ 
    // Steal the data 
    std::swap(my_data_length, other.my_data_length); 
    std::swap(my_data, other.my_data); 

    return *this; 
} 

什麼是noexcept這裏的目的是什麼？我知道這是命中，沒有例外應由下列函數拋出的編譯器，使用noexcept不會使自身的編譯器優化but how does this enable compiler optimizations?

Answer 1

恕我直言。有性狀STL：

std::is_nothrow_move_constructible 
std::is_nothrow_move_assignable 

STL containters像vector等使用這些特質來測試類型T，並使用移動構造函數和賦值，而不是拷貝構造函數和賦值。

爲什麼STL利用這些特性，而不是：

std::is_move_constructible 
std::is_move_assignable 

答：提供強大的異常保證。

Answer 2

首先我要說的是，在移動構造函數或移動任務中不應該拋出任何東西，似乎也沒有必要這樣做。唯一必須在構造函數/賦值運算符中完成的事情是處理已分配的內存和指向它們的指針。通常情況下，你不應該調用任何其他可以拋出的方法，並且你自己在構造函數/操作符中移動的方法不需要這樣做。但另一方面，調試消息的簡單輸出會打破此規則。

優化可以用一些不同的方法完成。由編譯器自動完成，也由使用構造函數和賦值運算符的不同代碼實現實現。看一下STL，如果使用異常或不是通過類型特徵實現的代碼，則有一些不同的代碼專業化。

編譯器本身可以更好地優化，同時保證任何代碼都不會丟失。編譯器通過你的代碼有一個保證的調用樹，它可以更好地內聯，編譯時間計算或以前的內容。可以完成的最小優化是不存儲關於處理拋出條件所需的實際堆棧幀的所有信息，例如堆棧上的取消分配變量等。

還有這裏的問題：noexcept, stack unwinding and performance

也許你的問題是一個重複這個問題？

一個也許有幫助的問題有關我在這裏找到這裏：Are move constructors required to be noexcept? 這討論了投擲移動操作的必要性。

這裏noexcept的用途是什麼？

至少保存一些程序空間，這不僅與移動操作相關，而且與所有功能相關。如果您的類與STL容器或算法一起使用，那麼它可以處理的不同，如果您的STL實現使用這些信息，則可以產生更好的優化。也許編譯器能夠得到更好的通用優化，因爲如果所有其他的東西都是編譯時間常量的話，那麼它就是已知的調用樹。

Answer 3

的noexcept對移動構造函數和賦值操作符的特殊重要性進行了詳細https://vimeo.com/channels/ndc2014/97337253

解釋基本上，它不會讓編譯器生成更好的代碼是傳統意義上實現「最佳化」。相反，它允許其他類型（如庫中的容器）在檢測到移動元素類型永遠不會拋出時採用不同的代碼路徑。這可以啓用替代代碼路徑，如果它們可能拋出（如因爲阻止容器遇到exception-safety guarantees）而不安全。

例如，當您在向量上做push_back(t)時，如果向量已滿（size() == capacity()），則需要分配新的內存塊並將所有現有元素複製到新內存中。如果複製任何元素拋出一個異常，那麼該庫只會銷燬其在新存儲中創建的所有元素，並釋放新內存，從而保持原始向量不變（從而滿足強大的異常安全保證）。將現有元素移動到新存儲區會更快，但是如果移動可能會導致所有已移動的元素已經被改變，並且無法實現強有力的保證，所以圖書館只會嘗試移動它們它知道不能拋出，它只能知道它們是否是noexcept。