क्यों कमजोर पॉइंटर्स अंतर्निहित सूचक का उपयोग नहीं कर सकते हैं?

Question

मैं यह पूछता हूं क्योंकि यह कई स्पष्ट कारणों से एक कमजोर प्रतिबंध है, लेकिन मुझे यकीन है कि सी ++ मानक लोगों के पास ऐसा करने का एक अच्छा कारण था, और मैं जानना चाहता हूं कि यह क्या है। ऐसा नहीं है क्योंकि इससे कोई फर्क नहीं पड़ता है, लेकिन इससे मुझे यह जानकर बेहतर महसूस होगा कि इसके लिए एक अच्छा कारण है।

यहां मेरा वर्तमान लेना है; जैसा कि मैंने देखा है कि कमजोर पॉइंटर्स के 2 मुख्य उपयोग हैं:

1) स्वामित्व लूप से बचने के लिए। 2) साझा पॉइंटर्स के आस-पास उछाल से जुड़े ओवरहेड को कम करने के लिए।

पूर्व को कम सेवा नहीं दी जाएगी और बाद में कमजोर_ptr.get() को लागू करके बेहतर सेवा दी जाएगी, तो यह क्यों अस्तित्व में नहीं है? बिंदु के लिए, कमजोर_ptr.get() कमजोर_ptr.lock() से अधिक कुशल नहीं होगा।() प्राप्त करें, या एक संकलक इसे अनुकूलित करने के लिए अनुकूलित कर सकता है?

Answer 1

एक कमजोर सूचक को यह जांचने में सक्षम होना चाहिए कि स्मार्ट पॉइंटर इसका संदर्भ अभी भी वैध है या नहीं। यदि यह ऐसा नहीं कर सका, तो आप यह नहीं जान सके कि get का परिणाम वास्तव में आपके द्वारा उपयोग किए जाने तक वैध था या नहीं।

यही कारण है कि lock है; यह आपको एक स्मार्ट सूचक देता है जो तब तक मान्य होगा जब तक आपको इसकी आवश्यकता हो (जो बहुत लंबा होने की उम्मीद नहीं है)।

यदि आप सीधे पहुंच चाहते हैं, तो आप वास्तव में क्या चाहते हैं एक साधारण "गूंगा" सूचक है।

Answer 2

1) स्वामित्व लूप से बचने के लिए। 2) साझा पॉइंटर्स के आसपास उछाल से जुड़े ओवरहेड को कम करने के लिए

पूर्व में कम सेवा नहीं होगी और बाद में कमजोर_ptr.get() को लागू करके बेहतर सेवा दी जाएगी, तो यह क्यों अस्तित्व में नहीं है? बिंदु के लिए, कमजोर_ptr.get() कमजोर_ptr.lock() से अधिक कुशल नहीं होगा।() प्राप्त करें, या एक संकलक इसे अनुकूलित करने के लिए अनुकूलित कर सकता है?

पूर्व सत्य, बाद में गलत है - कमजोर पॉइंटर्स जादुई रूप से कम लागत वाले साझा पॉइंटर्स नहीं हैं ... वे कार्यात्मक रूप से अलग हैं। आपको अपनी स्थिति के अनुरूप एक चुनने की जरूरत है।

कमजोर पॉइंटर्स का उपयोग करने का मुख्य कारण कुछ डेटा का ट्रैक रखना है, जिसका उपयोग आप अभी भी लटक रहे हैं, लेकिन बिना खुशी से जीवित रह सकते हैं। स्थापित करना जिसमें साझा पॉइंटर्स के उपयोगकर्ताओं के साथ दौड़ की स्थिति शामिल है, इसलिए जब तक आपके पास ऑब्जेक्ट के जीवनकाल में कुछ अंतर्दृष्टि अंतर्दृष्टि न हो, जिसका अर्थ है कि आप सुनिश्चित कर सकते हैं कि आपका कोड ऑब्जेक्ट के नष्ट होने से पहले पूरा हो सकता है, कच्चा सूचक बेकार होगा। यदि आपके अंदर अंदरूनी अंतर्दृष्टि है तो आप मूल रूप से कच्चे सूचक प्राप्त कर सकते हैं - कमजोर पॉइंटर के - लेकिन कमजोर पॉइंटर का डिज़ाइन आपको गलती से एक प्राप्त करने और असुरक्षित कोड बनाने का इरादा रखता है। दरअसल, इस तरह की अंतर्दृष्टि कोड के मध्यम/दीर्घकालिक विकास के मुकाबले नाजुक हो सकती है, इसलिए शायद यह बेहतर नहीं है कि आप इस तरह के अनुकूलन करने की कोशिश न करें जबतक कि आपको बिल्कुल जरूरी न हो।

शायद एक कमजोर सूचक मदद मिलेगी का अच्छा उपयोग का एक उदाहरण ...

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

Answer 3

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

चाहे साझा_ptr/weak_ptr को यह अनुमति देनी चाहिए (नॉटैड_प्टर कहें जहां लक्ष्य विनाश पर नोटड - शून्य नहीं है, लेकिन आवश्यक रूप से थ्रेड सुरक्षित नहीं है), या यह एक नया प्रकार का shared_ptr बहस योग्य होना चाहिए।

हम इसे एक नए प्रकार के स्मार्ट पॉइंटर जोड़कर हमारे कोड बेस में हल करते हैं, जो उन अर्थशास्त्र का समर्थन करता है। हालांकि, यह निश्चित रूप से इष्टतम नहीं है क्योंकि गैर मानकों के अनुरूप स्मार्ट पॉइंटर्स निश्चित रूप से परेशान हैं, लेकिन अतिरिक्त उपयोगी अर्थशास्त्र तथ्य के मुकाबले ज्यादा हैं, हम संभवतः स्मार्ट नहीं हैं [पन इरादा!] क्योंकि पूर्ण मानकीकरण समिति हैं: -)