爲什麼沒有std :: shared_ptr <T[]>專業化？

本標準規定的std::unique_ptr一個模板特其正確地調用其析構函數中delete[]：爲什麼沒有std :: shared_ptr <T[]>專業化？

void func() 
{ 
    std::unique_ptr<int[]> arr(new int[10]); 

    ....... 
}

隨着std::shared_ptr這種專業化是不可用的，所以有必要提供有刪除其正確調用delete[]：

void func() 
{ 
    // Usage 
    shared_ptr array (new double [256], [](double* arr) { delete [] arr; }); 

    .............. 
}

這是簡單的疏忽嗎？（就像std::copy_if一樣）或者是有原因的？

來源

2012-01-20 mark

N.B.有一個新的提議將C++ 17添加爲基於Boost的工作，請參閱http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3640.html –

請注意，很多在處理數組時，應該禁用'shared_ptr'機制，例如引用子對象的能力。 –

LWG（C++委員會圖書館工作組）簡要地考慮了可能性，但這個想法並非沒有爭議。儘管爭議主要是關於shared_ptr<T[]>提案中可能已被放棄的功能（在shared_ptr<T[]>上算術）。

但最終真正的真正原因是，儘管討論過了，但在LWG面前從來沒有寫實際的書面提案來做到這一點。它從來沒有冒充任何人的優先級列表（包括我自己的），足以讓時間寫出提案。

最近在幾個LWG成員中就這個話題重新開始了非正式對話，我親自對它進行了原型設計。但目前還沒有書面提案。我認爲這將是一個體面的工具箱中的附加工具。任何人都會猜測它是否會實際發生。

更新

shared_ptr爲陣列支持現在有一個TS草案：

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4077.html

更新（2017）

這現在支持C++ 17。參見案例3的shared_ptr::shared_ptr()

來源

2012-01-20 20:49:59

首先，「爲什麼不存在...」問題與我見過的真實答案，還有一個動態分配的數組？使用vector和std :: array，真的沒有看到需要（？） – Nim

+12

@Nim：'std :: unique_ptr '（存在）對於什麼時候開銷對你來說非常重要。與'vector '不同，'unique_ptr '不包括容量或甚至大小的開銷。客戶端可能需要爲大小添加外部開銷，但是如果數組永遠不會調整大小，而不是容量。現在這不會使'unique_ptr '更好'矢量'。事實上，我認爲與後者相比，前者的用例是罕見的。但前者的用例率並非零。 –

類似地，'shared_ptr '有時可以用較低的開銷替換'shared_ptr >'。 'boost :: shared_array '的存在和持續的支持是一些程序員發現偶爾有用的工具的論點。 –

爲什麼沒有std :: shared_ptr <T[]>專業化？

回答

相關問題