कस्टम स्मार्ट पॉइंटर रिमूवल टूल्स का उपयोग करके उचित डायनेमिक लाइब्रेरी बॉर्डर क्रॉसिंग कैसे सुनिश्चित करें

कई C ++ विशेषज्ञ स्मार्ट पॉइंटर्स के उपयोग की वकालत करते हैं, यह तर्क देते हुए कि आधुनिक C ++ से, new का स्पष्ट उपयोग पूरी तरह से गायब हो जाना चाहिए (ठीक है, कम से कम जब std::make_unique C ++ 14 में std::make_unique गया है)। सभी डायनैमिक मेमोरी एलोकेशन को किसी मानक लाइब्रेरी, या कंटेनर जैसे std::vector , या स्मार्ट पॉइंटर्स में एन्कैप्सुलेट किया जाना चाहिए।

मानक पुस्तकालय के स्मार्ट पॉइंटर्स को कॉन्फ़िगर किया जा सकता है ताकि वे स्वयं उन मेमोरी को मुक्त कर सकें जो वे कब्जा करते हैं। यह अवसर लेख के शीर्षक में लगाए गए प्रश्न के उत्तर के आधार पर रखा गया है।

एक वस्तु एक गतिशील पुस्तकालय की सीमा को पार कर रही है यदि इसे एक ब्लॉक में आरम्भ किया जाता है और दूसरे में उपयोग किया जाता है। ऐसा तब होता है, उदाहरण के लिए, किसी ऑब्जेक्ट को dll में इनिशियलाइज़ किया जाता है और उसके लिए एक पॉइंटर लौटाया जाता है।

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

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

हम कोडिंग पास करते हैं

हमारे पास दो परियोजनाएँ होंगी: पहली बस एक मुख्य फ़ाइल से बनेगी जिसमें लाइब्रेरी फैक्ट्री का उपयोग वस्तुओं को इनिशियलाइज़ करने के लिए किया जाएगा, दूसरा समस्या की स्थिति और उसके समाधान का वर्णन करेगा।
समस्या क्षेत्र सिंगलटन फैक्ट्री (समस्याग्रस्त कारखाने) है, जो ऑब्जेक्ट को इनिशियलाइज़ करता है और इसके लिए एक पॉइंटर लौटाता है। समाधान एक और सिंगलटन है, जो ऑब्जेक्ट को इनिशियलाइज़ करने के बाद, std::unique_ptr एक पॉइंटर देता है, जिसका अपना रिमूवल टूल है, जो DLL में मेमोरी को मुक्त करता है।
यदि आप USE_PROBLEMATIC_FACTORY_AND_CAUSE_HEAP_CORRUPTION की परिभाषा के साथ डिबग मोड में प्रोग्राम चलाते हैं, तो आप देख सकते हैं कि डीबगर ढेर को नुकसान का पता लगाता है।

मुख्य फ़ाइल

 // main.cpp #include <ProblematicFactory.h> #include <SafeFactory.h> //  undef  define,   assert'    #undef USE_PROBLEMATIC_FACTORY_AND_CAUSE_HEAP_CORRUPTION int main() { #ifdef USE_PROBLEMATIC_FACTORY_AND_CAUSE_HEAP_CORRUPTION { //     DLL auto wMyObject = ProblematicFactory::getInstance().create(); //       delete wMyObject; //  DLL           CLR DLL, //   ,  -     } #endif { auto wMyObject = SafeFactory::getInstance().create(); //      , wMyObject  //  ,    , //   MyClass.h (. ),   //      } { std::shared_ptr< MyClass > wMyObject = SafeFactory::getInstance().create(); } return 0; } 

समस्या का कारखाना

यह एक विशिष्ट कारखाना कार्यान्वयन है जो एक संकेतक को एक ऑब्जेक्ट पर लौटाता है जिसे लाइब्रेरी द्वारा बनाया जा सकता है।

 // ProblematicFactory.h #pragma once #include "DllSwitch.h" #include "MyClass.h" class LIBRARYFACTORY_API ProblematicFactory { public: static ProblematicFactory & getInstance() { static ProblematicFactory wProblematicFactory; return wProblematicFactory; } MyClass * create() const { return new MyClass; } private: ProblematicFactory() {}; }; 

सुरक्षित कारखाना

सिंथेटिक रूप से, इस कारखाने का उपयोग समस्याग्रस्त एक (मुख्य देखें) के समान है, लेकिन यहां सूचक को std::unique_ptr , std::unique_ptr ।

 // SaveFactory.h #pragma once #include "DllSwitch.h" #include "MyClass.h" #include <memory> class LIBRARYFACTORY_API SafeFactory { public: static SafeFactory & getInstance(); //  std::unique_ptr     , // ..       DLL.   //   ,   std::unique_ptr . //  ,      // ,    MyClass  std::default_delete inline std::unique_ptr< MyClass > create() const { return std::unique_ptr< MyClass >(doCreate()); } private: SafeFactory(); MyClass * doCreate() const; }; 

सीमा पार करना

 // MyClass.h #pragma once #include "DllSwitch.h" #include <memory> class LIBRARYFACTORY_API MyClass { }; namespace std { template<> class LIBRARYFACTORY_API default_delete< MyClass > { public: void operator()(MyClass *iToDelete) { delete iToDelete; } }; } 

उपरोक्त सभी फ़ाइलों में, DllSwitch.h हेडर फ़ाइल DllSwitch.h , जो LIBRARYFACTORY_API , इसकी सामग्री को परिभाषित करती है:

 // DllSwitch.h #pragma once #ifdef LIBRARYFACTORY_EXPORTS #define LIBRARYFACTORY_API __declspec(dllexport) #else #define LIBRARYFACTORY_API __declspec(dllimport) #endif 

UPD सभी फ़ंक्शन कार्यान्वयन को अलग-अलग फ़ाइलों में ले जाना चाहिए