C ++ लाइब्रेरी और फ्रेमवर्क कभी स्मार्ट पॉइंटर्स का उपयोग क्यों नहीं करते हैं?

156

मैंने कुछ लेखों में पढ़ा कि कच्चे पॉइंटर्स का उपयोग लगभग कभी नहीं किया जाना चाहिए। इसके बजाय उन्हें हमेशा स्मार्ट पॉइंटर्स के अंदर लपेटना चाहिए, चाहे वह स्कोप हो या शेयर्ड पॉइंटर्स।

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

बस यह सोचकर कि क्यों कई बड़े प्रोजेक्ट से बचने के लिए स्मार्ट पॉइंटर्स की सिफारिश की जाती है।

— लॉरेंट
स्रोत

22

आपके द्वारा नामांकित उन सभी पुस्तकालयों को कई साल पहले शुरू किया गया था। स्मार्ट पॉइंटर्स केवल C ++ 11 में सही मायने में मानक बन गए।

— क्रिसकॉक

22

स्मार्ट पॉइंटर्स में एक ओवरहेड (संदर्भ गिनती आदि) होता है - जो महत्वपूर्ण हो सकता है - उदाहरण के लिए एम्बेडेड / रीयल टाइम सिस्टम में। IMHO - स्मार्ट पॉइंटर्स आलसी प्रोग्रामर के लिए हैं। इसके अलावा बहुत सारे एपीआई सबसे कम सामान्य भाजक के लिए जाते हैं। जैसा कि मैं टाइप करता हूं, मुझे अपने पैरों के चारों ओर लपटें महसूस होती हैं!

— एड हील

93

@ एडीएचडी: आप अपने पैरों के चारों ओर आग की लपटों को महसूस कर सकते हैं इसका कारण यह है कि आप हर मामले में पूरी तरह से गलत हैं। उदाहरण के लिए, किस उपरि में है unique_ptr? कोई भी नहीं, कुछ भी नहीं। क्या Qt / WxWidgets को एम्बेडेड या रियल टाइम सिस्टम पर लक्षित किया जाता है? नहीं, वे एक डेस्कटॉप पर विंडोज / मैक / यूनिक्स के लिए अभिप्रेत हैं- सबसे अधिक। स्मार्ट पॉइंटर्स प्रोग्रामर के लिए हैं जो इसे सही करना चाहते हैं।

— पिल्ला

24

वास्तव में, मोबाइल फोन जावा चला रहे हैं।

— आर। मार्टिनो फर्नांडीस

12

स्मार्ट संकेत केवल सही मायने में सी ++ 11 में मानक? क्या??? इन चीजों का उपयोग 20 वर्षों से अधिक समय से किया जा रहा है।

— काज

124

इस तथ्य के अलावा कि कई पुस्तकालय मानक स्मार्ट पॉइंटर्स के आगमन से पहले लिखे गए थे, सबसे बड़ा कारण संभवतः एक मानक सी ++ एप्लीकेशन बाइनरी इंटरफेस (एबीआई) की कमी है।

यदि आप हेडर-ओनली लाइब्रेरी लिख रहे हैं, तो आप स्मार्ट पॉइंटर्स और मानक कंटेनरों को अपने दिल की सामग्री में पास कर सकते हैं। उनका स्रोत आपके पुस्तकालय में संकलित समय पर उपलब्ध है, इसलिए आप उनके इंटरफेस की स्थिरता पर निर्भर करते हैं, उनके कार्यान्वयन के बारे में नहीं।

लेकिन मानक ABI की कमी के कारण, आप आमतौर पर इन वस्तुओं को मॉड्यूल सीमाओं के पार सुरक्षित रूप से पारित नहीं कर सकते हैं। एक GCC shared_ptrसंभवतः MSVC से अलग है shared_ptr, जो एक इंटेल से भी भिन्न हो सकता है shared_ptr। समान संकलक के साथ भी , इन वर्गों को संस्करणों के बीच द्विआधारी संगत होने की गारंटी नहीं है।

लब्बोलुआब यह है कि यदि आप अपने पुस्तकालय के एक पूर्वनिर्मित संस्करण को वितरित करना चाहते हैं , तो आपको एक मानक एबीआई की आवश्यकता है जिस पर भरोसा करना है। C में एक नहीं है, लेकिन संकलक विक्रेता किसी दिए गए प्लेटफ़ॉर्म के लिए C पुस्तकालयों के बीच अंतर के बारे में बहुत अच्छे हैं - वास्तव में मानक हैं।

सी ++ के लिए स्थिति उतनी अच्छी नहीं है। व्यक्तिगत कंपाइलर अपने स्वयं के बायनेरिज़ के बीच व्यवधान को संभाल सकते हैं, इसलिए आपके पास हर समर्थित कंपाइलर के लिए एक संस्करण वितरित करने का विकल्प होता है, अक्सर जीसीसी और एमएसवीसी। लेकिन इसके प्रकाश में, अधिकांश पुस्तकालय सिर्फ एक सी इंटरफ़ेस निर्यात करते हैं - और इसका मतलब है कि कच्चे संकेत।

गैर-पुस्तकालय कोड, हालांकि, आमतौर पर कच्चे पर स्मार्ट पॉइंटर्स को प्राथमिकता देना चाहिए।

— जॉन पंडी
स्रोत

17

मैं आपके साथ सहमत हूँ, यहां तक कि एक std पास करने पर: स्ट्रिंग एक दर्द हो सकता है, यह C ++ के बारे में "पुस्तकालयों के लिए महान भाषा" के रूप में बहुत कुछ कहता है।

— 511 बजे Ha11owed

8

लब्बोलुआब यह अधिक पसंद है: यदि आप एक प्रीव्यू संस्करण को वितरित करना चाहते हैं तो आपको ऐसा हर कंपाइलर के लिए करना होगा जिसका आप समर्थन करना चाहते हैं।

— जोसेफ

6

@josefx: हाँ यह दुखद है लेकिन सच है, एकमात्र विकल्प COM या एक कच्चा C इंटरफ़ेस है। काश इस तरह की समस्याओं के लिए सी ++ कॉमिटी बिगड़ने लगती। मेरा मतलब है कि यह ऐसा नहीं है जैसे कि C ++ 2 साल पहले की एक नई भाषा है।

— रोबोट मेस

3

मैं गलत था क्योंकि यह गलत है। अधिकांश मामलों में एबीआई मुद्दे प्रबंधनीय से अधिक हैं। जबकि उपयोगकर्ता के अनुकूल, ABI भी शायद ही असंभव है।

— पिल्ला

4

@ नथन एडम्स: ऐसा सॉफ्टवेयर निस्संदेह प्रभावशाली और उपयोगी है। लेकिन यह गहरी समस्याओं के लक्षण का इलाज करता है: जीवनकाल और स्वामित्व के C ++ शब्दार्थ कहीं न कहीं दुर्बल और नगण्य हैं। अगर भाषा उन्हें अनुमति नहीं देती तो वे ढेर बग पैदा नहीं होते। तो यकीन है, स्मार्ट संकेत एक रामबाण नहीं हैं - वे पहली जगह में सी ++ का उपयोग करके होने वाले कुछ नुकसानों को फिर से प्राप्त करने का प्रयास कर रहे हैं।

— जॉन पूर्डी

40

इसके कई कारण हो सकते हैं। उनमें से कुछ को सूचीबद्ध करने के लिए:

स्मार्ट पॉइंटर्स हाल ही में मानक का हिस्सा बने। तब तक वे अन्य पुस्तकालयों का हिस्सा थे
मेमोरी लीक से बचने के लिए उनका प्राथमिक उपयोग है; कई पुस्तकालयों का अपना मेमोरी मैनेजमेंट नहीं है; आम तौर पर वे उपयोगिताओं और एपीआई प्रदान करते हैं
वे आवरण के रूप में कार्यान्वित किए जाते हैं, क्योंकि वे वास्तव में ऑब्जेक्ट हैं और न कि पॉइंटर्स। कच्चे संकेत की तुलना में अतिरिक्त समय / स्थान लागत होती है; हो सकता है कि पुस्तकालयों के उपयोगकर्ता इस तरह के ओवरहेड्स न चाहें

संपादित करें : स्मार्ट पॉइंटर्स का उपयोग करना पूरी तरह से डेवलपर की पसंद है। यह विभिन्न कारकों पर निर्भर करता है।

प्रदर्शन महत्वपूर्ण प्रणालियों में, आप स्मार्ट पॉइंटर्स का उपयोग नहीं करना चाह सकते हैं जो ओवरहेड उत्पन्न करता है
जिस परियोजना को पिछड़ी संगतता की आवश्यकता है, आप स्मार्ट पॉइंटर्स का उपयोग नहीं करना चाह सकते हैं जिसमें सी ++ 11 विशिष्ट विशेषताएं हैं

Edit2 नीचे दिए गए मार्ग के कारण 24 घंटों के अंतराल में कई डाउनवोट्स का एक तार है। मैं यह समझने में विफल रहा कि उत्तर को नीचे क्यों रखा गया है, हालांकि नीचे केवल एक ऐड-ऑन सुझाव है और उत्तर नहीं है।
हालाँकि, C ++ आपको हमेशा विकल्प खुला रखने की सुविधा देता है। :) जैसे

template<typename T>
struct Pointer {
#ifdef <Cpp11>
  typedef std::unique_ptr<T> type;
#else
  typedef T* type;
#endif
};

और अपने कोड में इसका उपयोग करें:

Pointer<int>::type p;

जो लोग कहते हैं कि एक स्मार्ट पॉइंटर और एक कच्चा पॉइंटर अलग हैं, मैं इससे सहमत हूं। ऊपर दिया गया कोड केवल एक विचार था जहां कोई ऐसा कोड लिख सकता है जो सिर्फ एक के साथ विनिमेय हो #define, यह बाध्यता नहीं है ;

उदाहरण के लिए, T*स्पष्ट रूप से हटाया जाना चाहिए , लेकिन एक स्मार्ट पॉइंटर नहीं करता है। हम Destroy()संभाल करने के लिए एक अस्थायी हो सकते हैं।

template<typename T>
void Destroy (T* p)
{
  delete p;
}
template<typename T>
void Destroy (std::unique_ptr<T> p)
{
  // do nothing
}

और इसे इस प्रकार उपयोग करें:

Destroy(p);

उसी तरह, एक कच्चे पॉइंटर के लिए हम इसे सीधे कॉपी कर सकते हैं और स्मार्ट पॉइंटर के लिए हम विशेष ऑपरेशन का उपयोग कर सकते हैं।

Pointer<X>::type p = new X;
Pointer<X>::type p2(Assign(p));

इस प्रकार Assign()है:

template<typename T>
T* Assign (T *p)
{
  return p;
}
template<typename T>
... Assign (SmartPointer<T> &p)
{
  // use move sematics or whateve appropriate
}

— iammilind
स्रोत

14

ऑन 3. कुछ स्मार्ट पॉइंटर्स में अतिरिक्त समय / स्थान लागत होती है, अन्य नहीं होते हैं, जिसमें std::auto_ptrलंबे समय तक मानक का हिस्सा रहा है (और ध्यान दें, मुझे पसंद है std::auto_ptrकि ऑब्जेक्ट बनाने वाले फ़ंक्शंस के लिए रिटर्न प्रकार, भले ही यह हो लगभग हर जगह बेकार)। C ++ 11 std::unique_ptrमें सादे सूचक पर कोई अतिरिक्त लागत नहीं है।

— डेविड रॉड्रिग्ज़ - dribeas

4

वास्तव में ... की उपस्थिति unique_ptrऔर गायब होने पर एक अच्छा समरूपता है auto_ptr, C ++ 03 को लक्षित करने वाले कोड को बाद में उपयोग करना चाहिए, जबकि C ++ 11 को लक्षित करने वाला कोड पूर्व का उपयोग कर सकता है। स्मार्ट पॉइंटर्स नहीं हैं shared_ptr , कई मानक हैं और कोई भी मानक नहीं है, जिसमें मानक के प्रस्ताव शामिल हैं जिन्हें अस्वीकार कर दिया गया हैmanaged_ptr

— डेविड रॉड्रिग्ज़ - dribeas

2

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

— laurent

7

स्मार्ट पॉइंटर्स का "अतिरिक्त समय / स्थान लागत" का कथन कुछ भ्रामक है; सभी स्मार्ट पॉइंटर्स को छोड़कर unique_ptrरनटाइम कॉस्ट, लेकिन unique_ptrअब तक जो सबसे ज्यादा इस्तेमाल किया जाता है। आपके द्वारा प्रदान किया गया कोड नमूना भी भ्रामक है, क्योंकि unique_ptrऔर T*पूरी तरह से अलग अवधारणाएं हैं। यह तथ्य कि आप दोनों का उल्लेख करते हैं, typeयह धारणा देता है कि उन्हें एक दूसरे के लिए स्वैप किया जा सकता है।

— शून्य-सूचक

12

आप इस प्रकार टाइप नहीं कर सकते, ये प्रकार किसी भी तरह से समतुल्य नहीं हैं। इस तरह से टाइपराइफ लिखना मुसीबत के लिए पूछ रहा है।

— एलेक्स बी

35

स्मार्ट पॉइंटर्स के साथ दो मुद्दे हैं (पूर्व C ++ 11):

गैर-मानक, इसलिए प्रत्येक पुस्तकालय अपने स्वयं के (NIH सिंड्रोम और निर्भरता के मुद्दों) को सुदृढ़ करने के लिए करते हैं
संभावित लागत

डिफ़ॉल्ट स्मार्ट सूचक, में है कि यह लागत से मुक्त है, है unique_ptr। दुर्भाग्यवश इसके लिए C ++ 11 चाल शब्दार्थ की आवश्यकता होती है, जो केवल हाल ही में दिखाई दिया। अन्य सभी स्मार्ट संकेत लागत (है shared_ptr, intrusive_ptr) या (आदर्श अर्थ विज्ञान की तुलना में कम है auto_ptr)।

कोने के चारों ओर सी ++ 11 के साथ std::unique_ptr, एक लाते हुए , यह सोचने के लिए लुभाया जाएगा कि यह आखिरकार खत्म हो गया है ... मैं इतना आशावादी नहीं हूं।

केवल कुछ प्रमुख कंपाइलर ही C ++ 11 को लागू करते हैं, और केवल उनके हाल के संस्करणों में। हम क्यूटी और बूस्ट जैसे प्रमुख पुस्तकालयों से थोड़ी देर के लिए सी ++ 03 के साथ संगतता बनाए रखने के लिए तैयार होने की उम्मीद कर सकते हैं, जो कुछ हद तक नए और चमकदार स्मार्ट पॉइंटर्स के व्यापक गोद लेने को रोकता है।

— मैथ्यू एम।
स्रोत

12

आपको स्मार्ट पॉइंटर्स से दूर नहीं रहना चाहिए, उनका उपयोग विशेष रूप से उन अनुप्रयोगों में किया जाता है जहाँ आपको किसी ऑब्जेक्ट को पास करना होता है।

लाइब्रेरीज़ या तो केवल एक मान लौटाती हैं या किसी ऑब्जेक्ट को पॉप्युलेट करती हैं। उनके पास आमतौर पर ऐसी वस्तुएं नहीं होती हैं, जिनका उपयोग बहुत से स्थानों पर करने की आवश्यकता होती है, इसलिए उनके लिए स्मार्ट पॉइंटर्स का उपयोग करने की कोई आवश्यकता नहीं है (कम से कम उनके इंटरफ़ेस में नहीं है, वे आंतरिक रूप से उनका उपयोग कर सकते हैं)।

मैं एक पुस्तकालय के रूप में उदाहरण ले सकता हूं जिस पर हम काम कर रहे हैं, जहां विकास के कुछ महीनों के बाद मैंने महसूस किया कि हमने केवल कुछ कक्षाओं (सभी वर्गों का 3-5%) में पॉइंटर्स और स्मार्ट पॉइंटर्स का उपयोग किया है।

संदर्भ द्वारा चर को पार करना ज्यादातर जगहों पर पर्याप्त था, जब भी हमारे पास कोई वस्तु होती थी, तो हम स्मार्ट पॉइंटर्स का उपयोग करते थे, जो कि एक पुस्तकालय होने पर हमें अशक्त और कच्चे संकेत देता था।

संपादित करें (मैं अपनी प्रतिष्ठा के कारण टिप्पणी नहीं कर सकता): संदर्भ द्वारा चर को पार करना बहुत लचीला है: यदि आप चाहते हैं कि वस्तु को आसानी से पढ़ा जाए तो आप एक कॉन्स्ट सन्दर्भ का उपयोग कर सकते हैं (आप अभी भी कुछ गंदा कास्ट कर सकते हैं जो वस्तु लिखने में सक्षम हो। ) लेकिन आपको अधिकतम सुरक्षा संभव है (यह स्मार्ट पॉइंटर्स के साथ समान है)। लेकिन मैं मानता हूं कि सिर्फ वस्तु वापस करने के लिए यह बहुत अच्छा है।

— रोबोट मेस
स्रोत

मैं आपसे असहमत नहीं हूँ, बिल्कुल, लेकिन मैं इस बात पर ध्यान दूंगा कि विचार का एक स्कूल है जो ज्यादातर मामलों में परिवर्तनशील संदर्भों को पारित करता है । मैं स्वीकार करता हूं कि मैं उस स्कूल का पालन करता हूं। मैं अपने तर्कों को संशोधित नहीं करने के लिए कार्यों को प्राथमिकता देता हूं। किसी भी दर पर, जहां तक मुझे पता है, C ++ के चर संदर्भ उन वस्तुओं के गलत इस्तेमाल को रोकने के लिए कुछ भी नहीं करते हैं, जिनका वे उल्लेख करते हैं, जो कि स्मार्ट पॉइंटर्स करने का इरादा रखते हैं।

— thb

2

उसके लिए आपके पास कास्ट है (लगता है कि मैं टिप्पणी कर सकता हूं: डी)।

— रोबॉट मेस

9

Qt ने जावा बनने के प्रयास में मानक पुस्तकालय के कई हिस्सों का फिर से आविष्कार किया। मेरा मानना है कि अब वास्तव में इसके अपने स्मार्ट पॉइंटर्स हैं, लेकिन सामान्य तौर पर, यह शायद ही डिजाइन का एक शिखर है। wxWidgets, जहाँ तक मुझे जानकारी है, प्रयोग करने योग्य स्मार्ट पॉइंटर्स लिखे जाने से बहुत पहले डिज़ाइन किया गया था।

बूस्ट के लिए, मैं पूरी तरह से उम्मीद करता हूं कि वे जहां भी उपयुक्त हों, स्मार्ट पॉइंटर्स का उपयोग करें। आपको अधिक विशिष्ट होना पड़ सकता है।

इसके अलावा, यह मत भूलो कि स्वामित्व को लागू करने के लिए स्मार्ट पॉइंटर्स मौजूद हैं। यदि एपीआई के पास कोई स्वामित्व शब्दार्थ नहीं है, तो स्मार्ट पॉइंटर का उपयोग क्यों करें?

— कुत्ते का बच्चा
स्रोत

19

Qt को बहुत अधिक कार्यक्षमता से पहले लिखा गया था, यह उन प्लेटफार्मों पर पर्याप्त रूप से व्यापक था जो इसका उपयोग करना चाहते थे। इसके पास लंबे समय तक स्मार्ट पॉइंटर्स हैं, और उनका उपयोग लगभग सभी Q * वर्गों में संसाधनों के निहित बंटवारे को करने के लिए करता है।

— रूबनेव

6

प्रत्येक GUI पुस्तकालय अनावश्यक रूप से पहिये को सुदृढ़ करता है। यहां तक कि स्ट्रिंग्स, क्यूटी के पास QString, wxWidgets है wxString, MFC के पास भयानक नाम है CString। std::stringGUI के 99% कार्यों के लिए UTF-8 पर्याप्त नहीं है?

— उलटा

10

@ जब QString बनाया गया था जब std :: string आसपास नहीं थी।

— MrFox

जाँच करें कि क्यूटी कब बनाया गया था और उस समय कौन से स्मार्ट पॉइंट उपलब्ध थे।

— Dainius

3

अच्छा प्रश्न। मैं उन विशिष्ट लेखों को नहीं जानता जिनके बारे में आप उल्लेख करते हैं, लेकिन मैंने समय-समय पर ऐसी ही बातें पढ़ी हैं। मेरा संदेह यह है कि इस तरह के लेखों के लेखक C ++ शैली प्रोग्रामिंग के खिलाफ पूर्वाग्रह का शिकार होते हैं। यदि लेखक C ++ में केवल तभी प्रोग्राम करता है, जब वह अवश्य होता है, तो जावा में लौटता है या जैसे ही वह कर सकता है, तो वह वास्तव में C ++ मानसिकता को साझा नहीं करता है।

एक को संदेह है कि कुछ या अधिकांश एक ही लेखक कचरा इकट्ठा करने वाले मेमोरी मैनेजर पसंद करते हैं। मैं नहीं, लेकिन मुझे लगता है कि वे अलग से करते हैं।

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

C ++ के बारे में उत्कृष्ट चीजों में से एक एम्बेडेड सिस्टम प्रोग्रामिंग के लिए इसका समर्थन है। नंगे बिंदुओं का उपयोग उसी का हिस्सा है।

अद्यतन: एक टिप्पणीकार ने सही ढंग से देखा है कि C ++ का नया unique_ptr(TR1 के बाद से उपलब्ध) संदर्भों की गणना नहीं करता है। टिप्पणीकार के पास "स्मार्ट पॉइंटर" की एक अलग परिभाषा भी है जो मेरे दिमाग में है। वह परिभाषा के बारे में सही हो सकता है।

आगे का अपडेट: नीचे टिप्पणी धागा प्रकाशित कर रहा है। यह सब पढ़ने की सिफारिश की जाती है।

— THB
स्रोत

2

एक शुरुआत के लिए, एम्बेडेड-सिस्टम प्रोग्रामिंग सभी प्रोग्रामिंग की एक विशाल अल्पसंख्यक है, और काफी अप्रासंगिक है। C ++ एक सामान्य उद्देश्य वाली भाषा है। दूसरे, shared_ptrएक संदर्भ गणना रखता है। कई अन्य स्मार्ट पॉइंटर प्रकार हैं जो एक संदर्भ गणना बिल्कुल नहीं रखते हैं। अंत में, उल्लिखित पुस्तकालयों को उन प्लेटफार्मों पर लक्षित किया जाता है जिनके पास बहुत सारे संसाधन हैं। ऐसा नहीं है कि मैं नीच था, लेकिन मैं यह कह रहा हूं कि आपकी पोस्ट गलत है।

— पिल्ला

2

@thb - मैं आपकी भावना से सहमत हूं। डेडएमजी - कृपया एम्बेडेड सिस्टम के बिना रहने की कोशिश करें। हां - कुछ स्मार्ट पॉइंटर्स में ओवरहेड नहीं होता है, लेकिन कुछ करते हैं। ओपी में पुस्तकालयों का उल्लेख है। उदाहरण के लिए बूस्ट में ऐसे हिस्से होते हैं जो एम्बेडेड सिस्टम द्वारा उपयोग किए जाते हैं - लेकिन स्मार्ट पॉइंटर्स कुछ अनुप्रयोगों के लिए अनुपयुक्त हो सकते हैं।

— एड हील

2

@ एडहेल: एम्बेडेड सिस्टम के बिना नहीं रहना! = उनके लिए प्रोग्रामिंग एक छोटा, अप्रासंगिक, अल्पसंख्यक नहीं है। स्मार्ट पॉइंटर्स हर उस स्थिति के लिए उपयुक्त हैं जिसमें आपको संसाधन के जीवनकाल का प्रबंधन करने की आवश्यकता होती है।

— Puppy

4

shared_ptrकोई उपरि नहीं है। यह केवल ओवरहेड है यदि आपको थ्रेड-सुरक्षित साझा स्वामित्व शब्दार्थ की आवश्यकता नहीं है, जो कि यह प्रदान करता है।

— आर। मार्टिनो फर्नांडीस 14

1

नहीं, share_ptr में थ्रेड-सुरक्षित साझा स्वामित्व शब्दार्थ के लिए आवश्यक आवश्यक ओवरहेड है; विशेष रूप से यह आपके द्वारा साझा की जा रही वास्तविक वस्तु से अलग एक ढेर ब्लॉक को आवंटित करता है, केवल रीफोकाउंट के भंडारण के उद्देश्य के लिए। intrusive_ptr अधिक कुशल है, लेकिन (जैसे shared_ptr) यह भी मानता है कि ऑब्जेक्ट का प्रत्येक पॉइंटर intrusive_ptr होगा। आप कस्टम रेफरी-काउंटिंग शेयर पॉइंटर के साथ intrusive_ptr की तुलना में भी कम ओवरहेड प्राप्त कर सकते हैं, जैसा कि मैं अपने ऐप में करता हूं, और फिर टी * का उपयोग करें जब भी आप गारंटी दे सकते हैं कि कम से कम एक स्मार्ट पॉइंटर टी * मान को रेखांकित करेगा।

— क्वर्टी

2

अन्य प्रकार के स्मार्ट पॉइंटर्स भी हैं। आप नेटवर्क प्रतिकृति जैसी किसी चीज़ के लिए एक विशेष स्मार्ट पॉइंटर चाहते हैं (एक जो पता लगाता है कि यह एक्सेस है और सर्वर में संशोधन करता है या कुछ ऐसे), परिवर्तनों का इतिहास रखता है, इस तथ्य को चिह्नित करता है कि इसे एक्सेस किया गया था, तो इसकी जांच की जा सकती है जब आप डिस्क और इतने पर डेटा को बचाते हैं। सुनिश्चित नहीं है कि ऐसा करना पॉइंटर में सबसे अच्छा समाधान है, लेकिन अंतर्निहित स्मार्ट पॉइंटर प्रकारों का उपयोग पुस्तकालयों में करने से लोगों को उन पर लॉक किया जा सकता है और लचीलापन खो सकता है।

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

सी के साथ एकीकरण एक और मुद्दा भी है।

एक अन्य मुद्दा स्मार्ट पॉइंटर्स एसटीएल का हिस्सा हैं। C ++ को STL के बिना प्रयोग करने योग्य बनाया गया है।

— डेविड सी। बिशप
स्रोत

" एक और मुद्दा स्मार्ट पॉइंटर्स एसटीएल का हिस्सा हैं। " वे नहीं हैं।

— उत्सुकता

0

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

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

— बदसूरत डेविस
स्रोत

3

"बूस्ट ओवरहेड" जैसी कोई चीज नहीं है।

— उत्सुकता

4

मैंने कभी भी अपने गेम इंजन को किसी उल्लेखनीय डिग्री तक साझा नहीं किया है। उन्होंने हालांकि उत्पादन और डिबगिंग की प्रक्रिया को समाप्त कर दिया है। इसके अलावा, आप वास्तव में "बूस्ट ओवरहेड?" यह कास्ट करने के लिए एक बहुत बड़ा कंबल है।

— derpface

@ कुरसीगुइ: यह उन सभी हेडर और मैक्रो + टेम्पलेट वूडू का संकलन है ...

— einpoklum