Effective Modern C++ 條款38 意識到線程句柄的析構函數的不同行為

shared state的存在很重要，因為future的析構函數的行為——該條款的話題——是由與它關聯的shared state決定的。特別是：

這些規則聽起來很復雜，但我們真正需要處理的是一個簡單“正常的”行為和一個單獨的例外而已。這正常的行為是：future的析構函數會銷毀future對象。那意思是，它不會join任何東西，也不會detach任何東西，它也沒有運行任何東西，它只是銷毀 future的成員變量。（好吧。實際上，它還多做了些東西。它減少了shared state裡的引用計數，這個shared state由future和被叫的std::promise共同操控。引用計數可以讓庫知道什麼時候銷毀**shared state，關於引用計數的通用知識，請看條款19.）

對於正常行為的那個例外，只有在future滿足下面全部條件才會出現：

只有當這些條件都被滿足時，future的析構函數才會表現出特殊的行為，而這行為是：阻塞直到異步運行的任務結束。特別說明一下，這相當於對運行著std::async創建的任務的線程執行隱式join。

這個例外對於正常的future析構函數行為來說，可以總結為“來自std::async的future在它們的析構函數裡阻塞了。”對於初步近似，它是正確的，但有時候你需要的比初步近似要多，現在你已經知道了它所有的真相了。

你可能又有另一種疑問，可能是“我好奇為什麼會有這麼奇怪的規則？”。這是個合理的問題，關於這個我只能告訴你，標准委員會想要避免隱式detach引發的問題（看條款37），但是他們又不想用原來的策略讓程序終止（針對可連接的線程，看條款37），所以他們對隱式join妥協了。這個決定不是沒有爭議的，他們也有討論過要在C++14中禁止這種行為。但最後，沒有改變，所以future析構函數的行為在C++11和C++14相同。

future的API沒有提供方法判斷future引用的shared state是否產生於std::async調用，所以給定任意的future對象，不可能知道它的析構函數是否會阻塞到異步執行任務的結束。這有一些有趣的含義：

// 這個容器的析構函數可能會阻塞
// 因為包含的future有可能引用了借助std::async發射的推遲任務的而產生的shared state
std::vector> futs;           // 關於std::future，請看條款39

class Widget {                // Widget對象的析構函數可能會阻塞
public:
    ...
private:
    std::shared_future fut;
};

當然，如果你有辦法知道給定的future不滿足觸發特殊析構行為的條件（例如，通過程序邏輯），你就可以斷定future不會阻塞在它的析構函數。例如，只有在std::async調用時出現的shared state才具有特殊行為的資格，但是有其他方法可以創建shared state。一個是std::packaged_task的使用，一個std::packaged_task對象包裝一個可調用的對象，並且允許異步執行並獲取該可調用對象產生的結果，這個結果就被放在shared state裡。引用shared state的future可以借助std::packaged_task的get_future函數獲取：

int calcValue();         // 需要運行的函數

std::packaged_task pt(calcValue);   // 包裝calcValue，因此它可以異步允許

auto fut = pt.get_future();     // 得到pt的future

在這時，我們知道future對象fut沒有引用由std::async調用的產生的shared state，所以它的析構函數將會表現出正常的行為。

一旦std::packaged_task對象pt被創建，它就會被運行在線程中。（它也可以借助std::async調用，但是如果你想要用std::async運行一個任務，沒有理由創建一個std::packaged_task對象，因為std::async能做std::packaged_task能做的任何事情。）

std::packaged_task不能被拷貝，所以當把pt傳遞給一個std::thread構造函數時，它一定要被轉換成一個右值（借助std::move——看條款23）：

std::thread t(std::move(pt));             // 在t上運行pt

這個例子讓我們看到了一些future正常析構行為，但如果把這些語句放在同一個塊中，就更容易看出來：

{           // 塊開始
    std::packaged_task pt(calcValue);

    auto fut = pt.get_future();

    std::thread t(std::move(pt));

   ...    // 看下面
}         // 塊結束

這裡最有趣的代碼是“…”，它在塊結束之前，t創建之後。這裡有趣的地方是在“…”中，t會發生什麼。有3個基本的可能：

換句話說，當你shared state對應的future是由std::packaged_task產生的，通常不需要采用特殊析構策略，因為操縱運行std::packaged_task的std::thread的代碼會在終止、join、detach之間做出決定。
*需要記住的2點：