🎮 🔰 👩🏾‍🔬 सी ++ में लिंक के साथ क्या गलत है ⛺️ 🚟 👩🏾‍🔬

अस्वीकरण: फिलहाल, मेरे पास C ++ 11 के साथ पर्याप्त अनुभव नहीं है, इसलिए सभी विचारों को C ++ 03 के संदर्भ में विशेष रूप से माना जाना चाहिए, हालांकि, मुझे इस लेख में चर्चा की गई समस्याओं के साथ C ++ नवाचारों की बातचीत पर चर्चा करने में खुशी होगी।

सी ++ में संदर्भ ऑपरेटर अधिभार तंत्र की वाक्यात्मक आवश्यकताओं को संतुष्ट करने के लिए दिखाई दिए। शुद्ध सी में कोई संदर्भ प्रकार नहीं होते हैं, इसके बजाय, लैवल्यू की अवधारणा है, जिसका वर्णन अस्पष्ट शब्द "असाइनमेंट ऑपरेटर के बाईं ओर क्या हो सकता है" द्वारा किया गया है।

//  C int a; int foo(int); a = 7; //  a - int 5 = 7; //   5 - int foo(42) = 7; //   foo(42) -  int

इस छोटे उदाहरण में, तीन अभिव्यक्तियाँ: चर a, शाब्दिक "5" और फ़ंक्शन कॉल फू (42) एक ही प्रकार के हैं - int, लेकिन केवल चर lvalue है और असाइनमेंट ऑपरेटर के बाईं ओर हो सकता है।

सी प्रोग्रामर के दृष्टिकोण से, अभिव्यक्ति "फू (42) = 7;" में सामान्य ज्ञान का अभाव है और संकलित नहीं किया जाना चाहिए, हालांकि, ऑपरेटर ओवरलोडिंग के आगमन के साथ, इस तरह की अभिव्यक्तियों के लिए आवश्यकता उत्पन्न हुई।

C ++ में, एरे एलिमेंट को एक्सेस करने का ऑपरेशन मेंबर फंक्शन ऑपरेटर [] (size_t n) को कॉल के रूप में माना जाता है। और इसे कुछ वापस करना चाहिए जो असाइनमेंट ऑपरेटर के बाईं ओर खड़ा हो सकता है। और हमें एक प्रकार की आवश्यकता है जो हमें इसका वर्णन करने की अनुमति देगा। तो लिंक थे।

एक संकेतक, एक सूचक की तरह, स्मृति में किसी वस्तु के पते को संग्रहीत करता है, हालांकि, यह एक सूचक द्वारा वाक्यविन्यास रूप से संक्षिप्त है। यह हमें उपरोक्त समस्याओं को हल करने की अनुमति देता है, लेकिन नई समस्याएं पैदा करता है।

भाषा सिंटैक्स लक्ष्य ऑब्जेक्ट और लिंक के बीच अंतर करने की अनुमति नहीं देता है - लिंक पर सभी ऑपरेशन वास्तव में ऑब्जेक्ट पर संचालन होते हैं। इसके परिणामस्वरूप:
1. लिंक को किसी अन्य ऑब्जेक्ट पर पुन: असाइन नहीं किया जा सकता है।
2. आप लिंक में मौजूद पते की तुलना किसी अन्य वस्तु या NULL के पते से नहीं कर सकते।

इन गुणों से, बदले में, अन्य प्रतिबंधों का पालन होता है:
3. लिंक को आरंभ में बनाया जाना चाहिए (क्योंकि बाद में इसे शुरू करना संभव नहीं है)।
4. लिंक में अशक्त पता नहीं हो सकता है (क्योंकि इसे सत्यापित और संसाधित करना असंभव है)।

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

हालांकि, एक विपरीत राय है (उदाहरण के लिए, Google और ट्रोलटेक इंजीनियर पॉइंटर्स पसंद करते हैं), क्योंकि लिंक के सिंटैक्स और शब्दार्थ के बीच विरोधाभास बहुत सारी समस्याएं पैदा करता है।

किसी फ़ंक्शन में आउटपुट तर्कों को पास करने के लिए लिंक का उपयोग करना, फ़ंक्शन कॉल को पढ़ते समय "आउटपुट" के तथ्य को बहुत ही स्पष्ट करता है:

  color.getHsv(&h, &s, &v); //      getHsv()    h,s,v color.getHsv(h, s, v); //   h,s,v

मूल्य द्वारा किसी वस्तु के अनुकूलित हस्तांतरण के लिए निरंतर संदर्भों का उपयोग वास्तविक तथ्य बन गया है। प्रविष्टि "कॉन्स्टल SomeClass & arg" को देखकर, मैं इस तथ्य के बारे में सोचूंगा कि इस मामले में कुछ संदर्भ क्लासक्लास वर्ग को इसे बदलने के अधिकार के बिना पारित किया गया है, और यह महत्वपूर्ण है कि फ़ंक्शन इस उदाहरण के साथ काम करे। मुझे लगता है कि SomeClass का एक मान यहाँ पारित किया जाता है। और एक बार जब मूल्य पारित हो जाता है, तो मैं इस वर्ग के किसी भी ऑब्जेक्ट को इस फ़ंक्शन के लिए मान के पास कर सकता हूं।

लिंक मेटा-प्रोग्रामिंग में कुछ कठिनाई पैदा करते हैं, Boost.Ref जैसी बैसाखी पैदा करते हैं।

लिंक STL कंटेनरों के तत्व नहीं हो सकते। एक ऐसे क्षेत्र के लिए जिसमें लिंक फ़ील्ड है, एक असाइनमेंट ऑपरेटर (गंदे हैक का सहारा लिए बिना) को लागू करना असंभव है। इसलिए, ऐसी कक्षाओं की वस्तुएँ कंटेनर के तत्व नहीं हो सकते हैं।

हाल ही में पकड़े गए बग के आधार पर:

 template<class T> T foo(T x) { ... } template<class T> class Bar { public: static T baz(T x) { return foo(x); } }; std::string str = Bar<std::string>::baz(getTitle()); //  ColorDescriptor& desc = Bar<ColorDescriptor&>::baz(getColorDescriptor()); // !

यहाँ एक और दिलचस्प उदाहरण है:

 template<class T> class SizeOfTest { public: static bool sizeOfIsOK() { return sizeof(SizeOfTest<T>) >= sizeof(T); } private: T m_data; }; struct BigData { char d[1000]; }; assert(SizeOfTest<int>::sizeOfIsOK()); //  assert(SizeOfTest<BigData>::sizeOfIsOK()); //  assert(SizeOfTest<BigData&>::sizeOfIsOK()); // !

इसलिए लिंक C ++ में पॉइंटर्स के लिए पूर्ण प्रतिस्थापन के रूप में काम नहीं कर सकता है। इसके लिए नहीं कि वे बनाए गए थे।

लेकिन दूसरी ओर, "साफ" पॉइंटर्स की मांग दिखाई देती है - पॉइंटर्स जिसके लिए टाइप सिस्टम यह सुनिश्चित करता है कि वे आरंभीकृत हैं न कि NULL। और सबसे दिलचस्प क्या है - गुण (3,4) उनकी प्रकृति से सूचक के शब्दार्थ के साथ संघर्ष नहीं करते हैं। समस्या केवल C ++ में उपलब्ध साधनों के सीमित चयन द्वारा बनाई गई है।

आइए थोड़ा सा सपना देखें और खुद को पिछड़े अनुकूलता के ढांचे से मुक्त करें।

यदि यह मेरी इच्छा थी, तो मैं अपने शब्दार्थों को संरक्षित करते हुए (3,4) बिंदुओं के गुण स्वयं बनाऊंगा। टी। ई।

 int a = 5, b = 5; int* p1; //  int* p2 = null; //  int* p3 = &a; int* p4 = &b; assert(p3 != p4); assert(*p3 == *p4); p3 = &b; assert(p3 == p4); int * p5 = std::min(p3, p4); int * p6 = new int(5); // new    ,    if (p5) { ... } //  -   bool      .

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

 int a = 5; int? b = 5; //   int int? c = null; //   int assert(a == b); assert(b != c); int* p0 = &a; int*? p1 = &a; int*? p2 = null; int*? p3 = &b; //  int?* p4 = &b; int?*? p5 = null; p5 = p4; p4 = p5; //  *p0 = 7; *p1 = 7; // : p1 -    if(p1 != null) { *?p1 = 7; } p0 = ?p1;

क्या बिना लिंक के ऐसा करना संभव है? आइये इसे आजमाते हैं।

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

इस अनुकूलन के संबंध में सही निर्णय लेने के लिए, आपको विचार करने की आवश्यकता है

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

प्रोग्रामर प्रत्येक फ़ंक्शन के प्रत्येक पैरामीटर के लिए इन सभी मापदंडों का विस्तार से विश्लेषण नहीं कर सकता है - यह बहुत समय लेने वाला कार्य है। इसके अलावा, परिणाम अलग-अलग लक्ष्य हार्डवेयर प्लेटफार्मों के लिए अलग-अलग होगा। इसलिए, यह निर्णय लेने वाले को संकलक को सौंपने के लिए, और संकलन के समय को कोड लिखने के समय से निर्णय स्थगित करने की सलाह दी जाती है।

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

कॉपी कंस्ट्रक्टर्स के बारे में क्या? यदि एक नियमित कार्य के लिए शब्दार्थ "एक कॉपी कंस्ट्रक्टर को इस तर्क के लिए बुलाया जा सकता है" उपयुक्त है, तो यह कॉपी कंस्ट्रक्टर तर्क के लिए अस्वीकार्य है, क्योंकि यह अनंत पुनरावृत्ति की अनुमति देता है। इस समस्या को कम से कम दो तरीकों से हल किया जा सकता है:

प्रतिलिपि निर्माता के लिए स्पष्ट रूप से एक अपवाद जोड़ें - कंपाइलर हमेशा संदर्भ द्वारा स्थानांतरण का चयन करेगा।
```
 class MyClass { public: MyClass(MyClass src) //    const MyClass& src. { ... } }; 
```
पॉइंटर से कॉपी कंस्ट्रक्टर को तर्क पास करें और इसे किसी तरह से सजाएं:
```
 class MyClass { public: MyClass(const MyClass* src, std::copy_ctor_tag) { ... } }; 
```

अब वापस ऑपरेटर ओवरलोडिंग के लिए।

शुद्ध सी में, केवल बयानों का एक सीमित सेट एक अंतराल वापस कर सकता है: सरणी का उपयोग, विभिन्न असाइनमेंट प्रकार, उपसर्ग वृद्धि और गिरावट, और खुद को डीरेंस। वह सब है। इन ऑपरेटरों के लिए, आप मैपिंग के अपने तरीके को फ़ंक्शन में बदल सकते हैं ताकि वे एक पॉइंटर लौटाएं:

 a[i] = b; *a.operator[](i) = b; (++i) = x; *i.operator++() = x; (x = y) = z; *x.operator=(y) = z; *p = d; *p.operator->() = d;

उसी समय, अनुमेय ऑपरेटर गैर-लोडिंग हो जाता है - इसके बजाय, ऑपरेटर -> सभी काम करता है।

अन्य सभी मामलों के लिए, लैवल्यू का उपयोग करने की संभावना कम से कम आश्चर्य के सिद्धांत का खंडन करती है - मुझे उम्मीद है कि मुझे कभी भी कोड को डिबग नहीं करना पड़ेगा जिसमें अभिव्यक्ति "a + b" अपने तर्कों में से एक को बदल देती है, या समझती है कि रिकॉर्ड "foo (42 = 7) की समीक्षा के दौरान क्या मतलब है" ? ”।

नियम का एक अपवाद I / O प्रवाह है। आप << ऑपरेटर के तर्क के रूप में स्ट्रीम को स्वयं पास नहीं कर सकते - इसे मूल्य द्वारा पास किया जाएगा। तो आपको कुछ पारित करने की आवश्यकता है जो स्ट्रीम ऑब्जेक्ट को संदर्भित करेगा और उसी समय सुरक्षित रूप से मूल्य द्वारा प्रेषित किया जा सकता है। यह एक स्ट्रीम का सूचक हो सकता है, या बेहतर, एक विशेष आवरण वस्तु:

 int main() { std::fstream filestr("test.txt", fstream::out); std::outref(&filestr) << "foo = " << foo << ", bar = " << bar << std::endl; return 0; } std::outref operator<<(std::outref ref, MyClass obj) { ref << obj.x; ref << obj.y; ref << obj.z; return ref; }

अगर मुझे कुछ याद नहीं है, तो यह बहुत संभावना है कि सी ++ में लिंक के बिना ऐसा करना काफी संभव था।

सारांश

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

सी ++ में लिंक के साथ क्या गलत है

सारांश

More articles: