2016-09-30 7 views
17

सी ++ 17 हमें std::pmr::memory_resource लाएगा जो स्मृति आवंटित करने और हटाने के लिए एक स्वच्छ इंटरफ़ेस है। Allocator अवधारणा के विपरीत, यह केवल है और कुछ भी नहीं। std::pmr::polymorphic_allocator भी होगा जो एक शास्त्रीय आवंटक में स्मृति संसाधन को लपेटता है ताकि इसका उपयोग मौजूदा कंटेनर के साथ किया जा सके।क्या नया सी ++ कोड आवंटकों के बजाय स्मृति संसाधनों का उपयोग करना चाहिए?

अगर मैं के बारे में एक नया कंटेनर लिखने के लिए कर रहा हूँ (या अन्य स्मृति के भूखे) सी ++ 17 और लक्षित कर बाद में टाइप करें, मैं संभाजक अवधारणा के खिलाफ प्रोग्रामिंग जारी रखना चाहिए या बल्कि सीधे नए और क्लीनर अमूर्त का उपयोग करें?

अभी तक, मेरे विचार इस तरह जाते हैं।

कारण allocators का उपयोग जारी रखना:

  • यह मानक पुस्तकालय और मौजूदा कोड के अनुरूप है। यहां तक ​​कि नए std::pmr::* कंटेनर उपनाम भी आवंटकों का उपयोग जारी रखते हैं।
  • चूंकि स्मृति संसाधन को std::pmr::polymorphic_allocator में लपेटा जा सकता है, इसलिए आवंटक इंटरफ़ेस अधिक सामान्य है और अधिक ग्राहकों की आवश्यकताओं को पूरा करता है।
  • मेमोरी संसाधन हमेशा रन-टाइम पॉलीमोर्फिज्म का उपयोग करते हैं, इसलिए उनके पास शून्य-ओवरहेड अमूर्तता की तुलना में मामूली अतिरिक्त रन-टाइम ओवरहेड होता है जो आवंटक प्रदान कर सकते हैं।
  • शायद किसी को वास्तव में आवंटक इंटरफ़ेस (जैसे कस्टम पॉइंटर प्रकार) के अन्य हिस्सों की आवश्यकता होती है जिसे शुद्ध स्मृति संसाधन द्वारा प्रदान नहीं किया जा सकता है।

कारण allocators के बजाय स्मृति संसाधनों का उपयोग शुरू करने के लिए:

  • संभाजक इंटरफ़ेस भद्दा और लागू करने के लिए कठिन है। std::pmr::memory_resource इंटरफ़ेस साफ़ और सीधा-आगे है।
  • चूंकि स्मृति संसाधन पॉलीमोर्फिक हैं, इसलिए वे कंटेनर के प्रकार को प्रभावित नहीं करते हैं जिसका अर्थ है कम टेम्पलेट इंस्टॉलेशन (और इसलिए शायद तेज़ संकलन और छोटे निष्पादन योग्य) और हमें अलग-अलग अनुवाद इकाइयों में अधिक कोड स्थानांतरित करने में सक्षम बनाता है।
  • यदि कोई ऑब्जेक्ट मेमोरी संसाधन का उपयोग करता है, तो यह हमेशा एक उप-ऑब्जेक्ट को तुरंत चालू कर सकता है जो स्मृति संसाधन को std::pmr::polymorphic_allocator में लपेटकर आवंटकों का उपयोग करता है। दूसरी तरफ दौर अधिक कठिन है।
  • स्मृति आवंटन वैसे भी एक अपेक्षाकृत काम-गहन कार्य है। एक वर्चुअल फ़ंक्शन कॉल अधिकतर ओवरहेड नहीं जोड़ता है, अपेक्षाकृत बोल रहा है।

क्या नई पुस्तकालय सुविधा का प्रभावी ढंग से उपयोग करने के लिए पहले से ही कोई सिफारिशें मौजूद हैं?

+1

आवंटक इंटरफ़ेस वास्तव में लागू करने के लिए कठिन नहीं है। सी ++ 11 ने इसे बहुत आसान बना दिया। आपको दो प्रकार के नाम, दो कार्य और दो तुलना की आवश्यकता है। –

+1

क्या स्मृति आवंटन "अपेक्षाकृत काम गहन" है आवंटक पर निर्भर करता है, है ना? यदि यह स्थानीय ढेर पर एक monotonic क्षेत्र से आवंटित करता है, तो यह बहुत महंगा और काफी अटूट नहीं हो सकता है। –

+0

@KerrekSB यह सच है। असल में, मैंने कभी इसे C++ 11 द्वारा प्रदान किए गए एडेप्टर के बिना लागू नहीं किया। फिर भी, यह वह नहीं है जिसे मैं सुरुचिपूर्ण मानता हूं। – 5gon12eder

उत्तर

8

इस बिंदु पर नहीं।

सी ++ में आवंटक वर्तमान में जितना आसान होता है उससे कहीं अधिक आसान होते हैं।

वे दोनों pmr और क्लासिक आवंटक समर्थन प्रदान करते हैं।

अधिक महत्वपूर्ण बात यह है कि पीएमआर आधारित आवंटन वर्षों से भारी उपयोग में नहीं रहा है। कोई भी कमजोरी अभी भी प्रकाश में आ सकती है।

फास्ट पूल आधारित आवंटकों, या यहां तक ​​कि निश्चित बफर वाले या एसबीओ एक्सटेंशन, वर्चुअलाइजेशन ओवरहेड को देख सकते हैं।

+2

इस उत्तर के लिए धन्यवाद जो मैं आम तौर पर सहमत हूं। हालांकि, मुझे अन्य लोगों के कहने के मामले में उत्तर स्वीकार करने से कुछ दिन पहले इंतजार करना पसंद है। कम परिचित लोगों के लिए: "पीएमआर" = "पॉलिमॉर्फिक मेमोरी रिसोर्स" और "एसबीओ" = "छोटे बफर ऑप्टिमाइज़ेशन", मुझे विश्वास है। – 5gon12eder

संबंधित मुद्दे