實施的unique_ptr：刪除未分配的對象

我的目標就是在這裏實現的unique_ptr的簡單版本，只提供一個構造函數，析構函數 - >，*和釋放（）。實施的unique_ptr：刪除未分配的對象

不過，我不知道該怎麼在一個的unique_ptr使用未分配的指針初始化的情況下做的。

如

int i = 0; 
unique_ptr<int> p{&i};

如果的unique_ptr只是調用刪除它擁有的指針，這將產生不確定的（和不受歡迎的）行爲，至少據我所知。我能做些什麼來防止這種情況發生？

編輯：我的問題嘗試如下...

template<typename T> 
class Uptr 
{ 
public: 
    Uptr<T>(T* pt) : mp_owned{pt} {} 
    ~Uptr<T>() {delete mp_owned;} 

    Uptr<T>(const Uptr<T>&) = delete; 
    Uptr<T>& operator=(const Uptr<T>&) = delete; 

    T& operator*() const {return *mp_owned;} 
    T* operator->() const {return mp_owned;} 

    T* release() {return mp_owned;} 

private: 
    T* mp_owned; 
};

來源

2017-04-09 Alden Bernitt

** real **'unique_ptr'也是如此。但要回答你的具體問題 - 你不能做任何事情，可靠/便攜地（至少不是我最後一次熟悉C++）。 –

你可以有一個標誌來控制你是否調用delete，並在堆棧分配對象上創建unique_ptr時進行設置。當然，它乞求的問題，爲什麼你要創建unique_ptrs堆棧分配對象在第一位 –

這沒有任何意義。「unique_ptr」的意義在於它是資源的唯一所有者。如果'stack'擁有它，那麼'unique_ptr'不應該指向它。 – Galik

是如何獲得一個指針值不能以編程方式檢查。在你的情況（這是極具代表性的真正的編程的大部分！），解決的辦法是文件的接口到要求指針值可刪除的。放在您的用戶，這需要用戶閱讀文檔，並按照它前提，並沒有這樣做，無法提供在語言的方法來驗證這些前提條件。您將負擔轉嫁給用戶。

這樣的前提負擔總是形成一種「技術債」，並且要避免它，就像你可以（但也許不是在運行時的成本爲代價）。例如，標準庫，我們強烈不鼓勵使用unique_ptr所有權回吐構造的，而是爲用戶使用make_unique，其中有一個有效的unique_ptr值無前提條件和結果。這種設計對於如何管理現實世界中的技術債務來說很模範。

來源

2017-04-09 23:02:56

不幸的是，您無法對此做任何事情：對象的所有權必須轉移到unique_ptr<T>，如果您在全局區域，靜態區域或自動區域中使用對象的地址，則這是不可能的。

從標準庫的實現，即std::unique_ptr<T,Deleter>，採用deleter參數，您可以使用它來而不是刪除任何東西。然而，這種使用是非常可疑的，因爲在這種情況下，根本不需要unique_ptr。

來源

2017-04-09 23:05:20 dasblinkenlight

實施的unique_ptr：刪除未分配的對象

回答

相關問題