2012-01-20 5 views
61

मानक std::unique_ptr की एक टेम्पलेट विशेषज्ञता जो सही ढंग से अपने नाशक से delete[] कॉल प्रदान करता है:क्यों कोई std :: shared_ptr <T[]> विशेषज्ञता नहीं है?

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

    ....... 
} 

std::shared_ptr के साथ इस विशेषज्ञता उपलब्ध नहीं है, इसलिए यह एक Deleter जो सही ढंग से delete[] कॉल प्रदान करने के लिए के लिए आवश्यक है:

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

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

क्या यह सिर्फ एक निरीक्षण है? (उसी तरह से std::copy_if है) या क्या कोई कारण है?

+3

एनबी के मामले 3 देखें। बूस्ट में काम के आधार पर सी ++ 17 के लिए इसे जोड़ने का एक नया प्रस्ताव है, http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3640.html –

+0

देखें कि बहुत कुछ सरणी के साथ काम करते समय 'shared_ptr' मशीनरी को अक्षम किया जाना चाहिए, जैसे कि सबबोजेक्ट को संदर्भित करने की क्षमता। –

उत्तर

65

एलडब्ल्यूजी (सी ++ समिति के पुस्तकालय कार्य समूह) ने संक्षेप में संभावना पर विचार किया लेकिन विचार विवाद के बिना नहीं था। यद्यपि विवाद मुख्य रूप से shared_ptr<T[]> प्रस्ताव में जोड़े गए एक फीचर के बारे में था जो कि जेटीसन (shared_ptr<T[]> पर अंकगणित) हो सकता था।

लेकिन आखिरकार वास्तविक वास्तविक कारण यह है कि हालांकि इस पर चर्चा की गई थी, ऐसा करने के लिए एलडब्ल्यूजी के सामने कभी भी एक वास्तविक लिखित प्रस्ताव नहीं था। इसने प्रस्ताव को लिखने में समय देने के लिए किसी की प्राथमिकता सूची (स्वयं सहित) को कभी भी बुलबुला नहीं किया।

कुछ एलडब्लूजी सदस्यों के बीच अनौपचारिक बातचीत ने हाल ही में इस विषय पर फिर से शुरू किया है, और मैंने व्यक्तिगत रूप से इसका प्रोटोटाइप किया है। लेकिन अभी भी इसके लिए कोई लिखित प्रस्ताव नहीं है। मुझे लगता है कि यह टूलबॉक्स में एक सभ्य अतिरिक्त उपकरण होगा। चाहे वह वास्तव में कभी भी होगा या नहीं, किसी का अनुमान है।

अद्यतन

सरणी shared_ptr के लिए समर्थन अब एक मसौदा टीएस है:

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

अद्यतन (2017)

यह अब में सी ++ 17 समर्थित है। shared_ptr::shared_ptr()

+2

पहले "क्यों नहीं है ..." एक वास्तविक उत्तर के साथ सवाल है जिसे मैंने देखा है, गतिशील रूप से आवंटित सरणी भी? वेक्टर और std :: सरणी के साथ, वास्तव में आवश्यकता (?) – Nim

+12

@Nim: 'std :: unique_ptr ' (जो मौजूद है) के लिए अच्छा नहीं है जब ओवरहेड आपके लिए बेहद महत्वपूर्ण है। 'वेक्टर ' के विपरीत, 'unique_ptr 'क्षमता, या यहां तक ​​कि आकार के लिए ओवरहेड शामिल नहीं है। क्लाइंट को आकार के लिए बाहरी ओवरहेड जोड़ने की आवश्यकता होगी, लेकिन अगर सरणी का आकार कभी नहीं बदला जाता है, तो क्षमता के लिए नहीं। अब यह 'unique_ptr 'बेहतर' वेक्टर ' नहीं बनाता है। दरअसल, मुझे लगता है कि पूर्व के उपयोग के मामले बाद के तुलना में दुर्लभ होंगे। लेकिन उपयोग केस दर पूर्व के लिए शून्य नहीं है। –

+3

गुणात्मक रूप से, 'shared_ptr ' कभी-कभी 'ओवर_प्टर >' को निम्न ओवरहेड के साथ बदल सकता है। 'बूस्ट :: shared_array 'का अस्तित्व और निरंतर समर्थन एक तर्क है कि कुछ प्रोग्रामर कभी-कभी ऐसे टूल को उपयोगी पाते हैं। –