आवंटक :: संदर्भ चरणबद्ध क्यों किया जा रहा है?

Question

तो मैं std::vector के विनिर्देश को देख रहा था और देखा कि reference टाइपपीफसे सी ++ 03 से value_type& में C++ 11 में बदल गया है। मैं आश्चर्यचकित था, इसलिए मैंने गहरी लगना शुरू कर दिया है।

C++ में 03 §20.1.5 [lib.allocator.requirements] वहाँ तालिका 32 जिसमें X::reference होने की T& और X::const_referenceT const& होने के लिए परिभाषित किया गया है परिभाषित किया गया है।

हालांकि, सी ++ 11 §17.6.3.5 [allocator.requirements] में तालिका 28 है जिसमें reference और const_reference गुम हैं।

अगला हमारे पास §20.6.8 std::allocator_traits सी ++ 11 में जोड़ा गया है जिसमें reference शामिल नहीं है। लेकिन §20.6.9 std::allocator करता है।

अंत में, वहाँ §23.2.1 [container.requirements.general] जो X::reference परिभाषित "T की lvalue" होने के लिए और X::const_reference "T की स्थिरांक lvalue" किया जाना है।

तो, मैं googled है और इस पत्र (1, 2) कि संभाजक आवश्यकताओं से reference को हटाने का प्रस्ताव मिला, लेकिन यह इसके पीछे किसी भी तर्क उल्लेख नहीं है। लेकिन LWG issue भी है जो परिवर्तन का विरोध करता है।

इसके अलावा, मैं पाया है the interview with Alexander Stepanov जिसमें उन्होंने बात करती है reference कैसे समाहित मशीन विशिष्ट स्मृति लेआउट और Herb Sutter's post जिसमें उन्होंने कंटेनर तत्वों, कंटेनर आवश्यकताओं और कैसे std::vector<bool> एक कंटेनर नहीं है की ओर इशारा लेने के बारे में बात करती है।

तो, आप इन सब के बारे में क्या सोचते हैं? reference उपयोगी था, क्या यह इसके उद्देश्य की सेवा करता था? "फैंसी" संदर्भ मानक में कैसे फिट होते हैं? क्या यह पूरी तरह से उन्हें खत्म करने के लिए एक साहसिक कदम है, अधिक सख्त कंटेनर आवश्यकताओं को बनाते हैं और std::vector<bool> को हटा देते हैं?

Answer 1

the interview with Alexander Stepanov में उन्होंने उल्लेख किया कि मानक पुस्तकालय में एसटीएल जोड़ने के प्रस्ताव के दौरान उन्हें स्मृति मॉडल से एक अमूर्त बनाने के लिए कहा गया था। इस प्रकार, आवंटकों का जन्म हुआ था। LWG issue में कार्यान्वयन का एक उदाहरण है जहां कस्टम आवंटक के reference को T __far& माना जाता है।

लेकिन अज्ञात कारणों से, क्योंकि मैं खोज करने के लिए है कि ज्यादा समय नहीं है तुम्हारे पास के लिए, सी ++ 03 मानक है §20.1.5 p4 में निम्न पाठ:

कंटेनरों के क्रियान्वयन इस में वर्णित अंतर्राष्ट्रीय मानक को यह मानने की अनुमति है कि उनके आवंटक टेम्पलेट पैरामीटर तालिका 32 में से परे निम्नलिखित दो अतिरिक्त आवश्यकताओं को पूरा करता है।

- दिए गए आवंटक प्रकार के सभी उदाहरणों को एक दूसरे के लिए आवश्यक होना आवश्यक है और हमेशा एक दूसरे के के बराबर तुलना करें।

- टाइप किए गए सदस्य पॉइंटर, const_pointer, size_type, और difference_type क्रमश: टी *, टी कॉन्स *, size_t, और ptrdiff_t होने की आवश्यकता है।

यह प्रभावी ढंग से कस्टम कंटेनर के साथ इंटरऑपरेट करने के लिए कस्टम मेमोरी मॉडल आवंटक की क्षमता को हरा देता है।

सभी पूर्व-सी ++ 11 कागजात के लिए मेरी खोज के दौरान "आवंटक" शब्द का उल्लेख करते हुए मुझे मानक से उन शब्दों को हटाने के लिए एक बड़ी सहमति मिली है। अंत में, this paper निम्नलिखित टिप्पणियों के साथ उन्हें हटाने का प्रस्ताव करता है:

वीज़ल शब्द चले गए हैं। अपना गिलास उठाएं और टोस्ट बनाएं।

विजय? क्या हम अंततः हमारे मेमोरी मॉडल के साथ जंगली जा सकते हैं? नहीं इतना अधिक। अन्य चीजों के अलावा, एक ही पेपर आवंटन आवश्यकताओं से reference को हटाने का प्रस्ताव करता है। और ऐसा लगता है कि इसे मानक में वोट दिया गया था।

LWG issue कि मैंने पहले बताया परिवर्तन का विरोध करता है, लेकिन यह निम्न कथन से बंद हो गया:

कोई आम सहमति एक परिवर्तन

तो यह allocators का मूल उद्देश्य की तरह दिखता है बनाने के लिए नहीं है आज बहुत महत्वपूर्ण है। यहाँ Wikipedia क्या कहना चाहता है है:

allocators की वर्तमान उद्देश्य अंतर्निहित हार्डवेयर के पते मॉडल अनुकूल करने के लिए करने के बजाय, कंटेनर के भीतर स्मृति आवंटन से अधिक प्रोग्रामर नियंत्रण दे रहा है। वास्तव में, संशोधित मानक ने आवंटकों की क्षमता को सी ++ एड्रेस मॉडल में विस्तारित करने के लिए औपचारिक रूप से (और जानबूझकर) अपने मूल उद्देश्य को समाप्त करने की क्षमता को समाप्त कर दिया।

अंत में, Container::reference के पास आवंटकों के साथ कुछ लेना देना नहीं है। यह प्रॉक्सिज्ड संग्रह which are not actually containers के लिए अनुमति देने के लिए बनाया गया था। तो यह यहाँ रहने के लिए है। वैसे, ऐसा लगता है कि यह एक और उदाहरण है कि मानक में अंतिम शब्द मूल इरादों के खिलाफ कैसे जाते हैं।

Answer 2

क्योंकि नेस्टेड टाइपपीफ अनिवार्य है। स्कॉट Meyers 'प्रभावी एसटीएल, पेज 49:

स्टैंडर्ड को स्पष्ट रूप से पुस्तकालय कार्यान्वयन माना कि हर संभाजक के सूचक typedef टी * और हर संभाजक के संदर्भ typedef के लिए एक पर्याय है की अनुमति देता है टी &

रूप में ही है

Answer 3

http://en.wikipedia.org/wiki/Allocator_(C%2B%2B)

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

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

हालांकि, इस समय प्रदर्शन की दंड का प्रदर्शन किया गया था, जो उस समय अस्वीकार्य समझा जाता था। इसके अलावा, यदि आप इसके बारे में सोचते हैं, तो यह है कोड में काम करना लगभग असंभव है। प्रत्येक void func(const string&) को template<class allocator> void func(allocator::reference) में बनाना होगा, जो एक गैर-कटौतीत्मक संदर्भ है ताकि आप हा फ़ंक्शन कॉल (func<std::allocator<std::string>::const_reference>(username)) में आवंटक को स्पष्ट रूप से लिखना है, जो कोई भी नहीं करेगा, जिससे जीसी ठीक से काम नहीं करेगा। आजकल, आवंटकों केवल सार स्मृति आवंटन/deallocation।