मेरा एक प्रोजेक्ट के लिए, मैं स्क्रैच से कुछ एसटीएल कंटेनर लिख रहा हूं (मेरे कारण हैं)। चूंकि मैं एसटीएल की कार्यक्षमता और इंटरफेस की नकल कर रहा हूं, इसलिए मैं नीति के साथ रखने के लिए अपनी पूरी कोशिश कर रहा हूं "यदि यह मानक निर्माण के समान नाम है, तो यह यथासंभव मानक के अनुरूप होगा।"std :: आवंटक बनाम/बनाम बनाम प्लेसमेंट नया/पी-> ~ टी()
तो, निश्चित रूप से मेरे कंटेनर आवंटकों को टेम्पलेट पैरामीटर के रूप में लेते हैं, जो बहुत अच्छा है क्योंकि यह कुछ कस्टम आवंटन योजनाओं के लिए अनुमति देता है। मेरे प्रश्न पर।
std::allocator इंटरफ़ेस ऑब्जेक्ट निर्माण से स्मृति आवंटन को अलग करता है। इसी प्रकार यह विनाश से विनाश को अलग करता है। यह समझ में आता है कि आप कहां से स्मृति प्राप्त करते हैं, सी ++ में किसी ऑब्जेक्ट को ठीक से बनाने के लिए अप्रासंगिक है।
तो दो निर्माण/आवंटन रद्द कार्य करता है जो डिफ़ॉल्ट कार्यान्वयन (एक पुस्तक से सीधे उठा लिया) के लिए इस तरह दिखना हैं:
void construct(pointer p, const T& val) { new(p) T(val); }
void destroy(pointer p) { p->~T(); }
के रूप में आप का निर्माण देख सकते हैं बस प्लेसमेंट नई कॉल करता है और बस नाशक कॉल नष्ट ।
क्या प्लेसमेंट नए और विनाशक वाक्यविन्यास का उपयोग करके इनका उपयोग करने का कोई कारण है? क्या एक "सही" आवंटक इन्हें किसी अन्य तरीके से कार्यान्वित कर सकता है? या क्या मैं गारंटी देता हूं कि मानक के अनुरूप सभी आवंटन कार्यान्वयन में इस तरह से लागू विधियों का निर्माण/नष्ट होगा?
अधिक बिंदु पर, क्या यह कहना सुरक्षित है कि मैं हमेशा अपने कंटेनर के तत्वों के निर्माण के लिए std::uninitialized_copy और std::uninitialized_fill का उपयोग कर सकता हूं?
धन्यवाद।
हाँ, यह एक अच्छा बिंदु है, यह "पोस्ट-आवंटन/पूर्व-निर्माण" लॉगिंग या मेमलेक ट्रैकिंग के लिए एक अच्छा हुक हो सकता है। –
यह उत्तर सही है लेकिन थोड़ा भ्रामक है। लॉगिंग जैसे दुष्प्रभाव वास्तव में सही अपवाद सुरक्षा के साथ करना मुश्किल है। अधिकतर अनुकूलन एम्बेडेड नई अभिव्यक्ति के समायोजन द्वारा होता है, उदा। कन्स्ट्रक्टर तर्क। Https://groups.google.com/a/isocpp.org/d/topic/std-discussion/yZLnYy_y2z0/discussion देखें – Potatoswatter