स्थिर चर और एक दूसरे के लिए निष्पादन योग्य मॉड्यूल के स्थैतिक लिंकिंग का उपयोग करना

गुड फ्राइडे की शाम!

आज मैं स्टैटिक वैरिएबल के कुछ कपटी फीचर्स के बारे में बात करना चाहता हूं, जिसमें एक्जीक्यूटेबल मॉड्यूल्स की गलत लिंकिंग है। मैं अपने वास्तविक अभ्यास से एक समस्या दिखाऊंगा जिसे हर कोई अनुभव कर सकता है।
मैं सब कुछ काफी विस्तार से चबाता हूं, इसलिए "अनुभवी" और लाल आंखों वाले लोगों को लग सकता है कि मैं "सैंडबॉक्स में चोंच मार रहा हूं", लेकिन यह लेख उनके लिए ही नहीं है।

आइए एक स्थिति की कल्पना करें: एक स्थिर पुस्तकालय (एफबीआई) में लागू कुछ वर्ग है। यह पुस्तकालय कार्यान्वयन मॉड्यूल (dll) द्वारा सांख्यिकीय रूप से बाध्य है। इसके अलावा यह निष्पादन योग्य मॉड्यूल (exe) भी इस dll को सांख्यिकीय रूप से बांधता है। इसके अलावा, Exe मॉड्यूल स्टेटिक लाइब्रेरी (lib) को स्टेटिकली लिंक करता है।
कुछ इस तरह:



उदाहरण के लिए, निम्नलिखित तर्क है: वास्तव में, कुछ के लिए कुछ उपकरण लागू किया जाता है। इस टूल के आधार पर dll की कुछ कार्यक्षमता है। Exe इस कार्यक्षमता के लिए एक परीक्षण लागू करता है। Dll स्वयं टूल क्लास (जो lib'e में स्थित है) को निर्यात नहीं करता है, इसलिए परीक्षण में libs के स्थैतिक लिंकिंग की आवश्यकता होती है।
बता दें कि इंस्ट्रूमेंटल क्लास में एक स्टैटिक वेरिएबल होता है। और dll में इस वर्ग को बनाने के लिए एक फ़ंक्शन है, और ऑब्जेक्ट को मूल्य द्वारा वापस किया जाता है।
यहाँ एक विस्तारित रूपरेखा है:


यहाँ C ++ कोड है:

• lib
  
  ListAndIter.h

  #pragma once #include <list> using namespace std; class ListAndIter { private: std::list<int>::iterator iter; static std::list<int> &getList(); public: void foo(); ListAndIter(); ListAndIter(ListAndIter& rhs); ~ListAndIter(); }; 

  
  
  ListAndIter.cpp

   #include "ListAndIter.h" ListAndIter::ListAndIter() { getList().push_front(0); iter = getList().begin(); } ListAndIter::ListAndIter(ListAndIter& rhs) { this->iter = rhs.iter; rhs.iter = getList().end(); } std::list<int> & ListAndIter::getList() { static std::list<int> MyList; return MyList; } ListAndIter::~ListAndIter() { if (iter != getList().end()) getList().erase(iter); } void ListAndIter::foo() { } 

  
  
  
  
• dll
  
  GetStaticObj.h

   #pragma once #include "ListAndIter.h" #ifdef _DLL_EXPORTS #define _DLL_EXP __declspec(dllexport) #else #define _DLL_EXP __declspec(dllimport) #endif _DLL_EXP ListAndIter GetStaticObj(); 

  
  
  GetStaticObj.cpp

   #include "GetStaticObj.h" ListAndIter GetStaticObj() { ListAndIter obj; obj.foo(); return obj; } 

  
  
  
  
• exe
  
  main.cpp

   #include "GetStaticObj.h" int main() { ListAndIter obj = GetStaticObj(); obj.foo(); } 

  
  
  
  

जैसा कि आप कोड से देख सकते हैं, एक विशेष फ़ंक्शन फू है जो आरवीओ को बायपास करने का कार्य करता है ताकि कॉपी कंस्ट्रक्टर को बुलाया जाए। आपको याद दिला दूं कि dll मॉड्यूल और exe मॉड्यूल दोनों एक दूसरे से स्वतंत्र रूप से इकट्ठे होते हैं, इसलिए उन्हें एक स्थिर चर के अस्तित्व के बारे में पता होना चाहिए और इसलिए उन्हें अपने दम पर बनाना चाहिए।

ListAndIter वर्ग का ऑब्जेक्ट कॉपी कंस्ट्रक्टर के माध्यम से लौटाया जाता है, इसलिए जब कोई ऑब्जेक्ट exe मॉड्यूल की तरफ से प्राप्त होता है, तो स्थिर चर के सभी संदर्भ अमान्य हो जाएंगे। चरणों में, यह इस तरह दिखता है:

1. * .exe: GetStaticObj () फ़ंक्शन को कॉल करें।
2. Dll.dll: ListAndIter वर्ग का एक अस्थायी ऑब्जेक्ट बनाना। शून्य को सूची में रखा गया है, यह पुनरावृत्त इसे इंगित करता है। इसके अलावा, इस समय, एक्स-मॉड्यूल के किनारे स्थित स्थिर चर क्रमशः खाली है, पुनरावृत्त मान्य नहीं है।
3. Dll.dll: कॉपी कंस्ट्रक्टर को क्लास ListAndIter के ऑब्जेक्ट के लिए कहा जाता है। अस्थायी वस्तु के लिए एक पुनरावृत्त अमान्य हो गया है। नई ऑब्जेक्ट के लिए, पुनरावृत्ति DLL.dll से सूची को इंगित करता है, हालांकि ऑब्जेक्ट स्वयं एक्स-मॉड्यूल के किनारे पर बनाया गया है।
4. Dll.dll: श्रेणी ListAndIter की एक अस्थायी ऑब्जेक्ट को नष्ट कर दिया। चूंकि पुनरावृत्त मान्य नहीं है, इसलिए कोई कार्रवाई नहीं होती है।
5. * .exe: ओब्जेक्ट ऑब्जेक्ट के लिए डिस्ट्रक्टर को कहा जाता है। जब GetList () समाप्ति () के साथ एक पुनरावृत्ति की तुलना करने की कोशिश कर रहा है, तो एक विंडोज त्रुटि पॉप अप होती है: "Iterter संगत नहीं हैं।" यही है, "अन्य सूची" से एक पुनरावृत्ति।

आइए स्थैतिक पुस्तकालय पर एक्स-मॉड्यूल की निर्भरता को हटाकर इस स्थिति को ठीक करने का प्रयास करें। फिर स्थैतिक पुस्तकालय की सभी कार्यक्षमता को dll के माध्यम से निर्यात करने की आवश्यकता है (नीचे कोड देखें):


कोड परिवर्तन:

• एक नया साझा किया गया। हेडर फ़ाइल। यह निर्यात मैक्रो का वर्णन करता है। फ़ाइल को lib में रखा:
  
  shared.h

   #pragma once #ifdef _DLL_EXPORTS #define _DLL_EXP __declspec(dllexport) #else #define _DLL_EXP __declspec(dllimport) #endif 

  
  
• ListAndIter.h में निर्यात निर्देश जोड़े:
  
  ListAndIter.h

   #pragma once #include <list> #include "shared.h" using namespace std; class ListAndIter { private: std::list<int>::iterator iter; _DLL_EXP static std::list<int> &getList(); public: _DLL_EXP void foo(); _DLL_EXP ListAndIter(); _DLL_EXP ListAndIter(ListAndIter& rhs); _DLL_EXP ~ListAndIter(); }; 

  
  
• Dll में, मैंने तदनुसार निर्यात मैक्रो घोषणाओं को हटा दिया:
  
  GetStaticObj.h

   #pragma once #include "ListAndIter.h" #include "shared.h" _DLL_EXP ListAndIter GetStaticObj(); 

  
  
  
  

अब ऑब्जेक्ट केवल dll साइड पर बनाया और डिलीट किया जाएगा। एक्स-मॉड्यूल में कोई स्थिर चर नहीं होगा और ऐसा कोड सफलतापूर्वक काम करेगा।

अब मान लेते हैं कि अगर ListAndIter वर्ग एक बॉयलरप्लेट बन जाए तो क्या होगा:



टेम्पलेट और ऐसी कक्षाओं की सभी वस्तुओं के प्रत्येक पूर्ण विशेषज्ञता के लिए, एक स्थिर चर होना चाहिए।
सबसे पहले, हम हेडर फ़ाइल में टेम्प्लेट क्लास के कार्यान्वयन को रखने के लिए बाध्य हैं, क्योंकि संकलन चरण में टेम्पलेट्स का पता चलता है।
यदि स्थिर चर वर्ग का सदस्य है, तो हमारी परियोजना को सफलतापूर्वक इकट्ठा करने के लिए, हम उपयोग किए गए सभी मॉड्यूल में इन चर को स्पष्ट रूप से आरंभ करने के लिए मजबूर हैं। इस मामले में, हम स्पष्ट रूप से दो स्थिर चर बनाते हैं, जो हमें 1 उदाहरण पर वापस लौटता है।
अन्यथा, यदि स्थैतिक चर वर्ग का सदस्य नहीं है, लेकिन स्थैतिक विधि के माध्यम से बनाया जाता है, तो इस मामले में यह भी बनाया जाता है, लेकिन पहले से ही हमारे लिए निहित है। त्रुटि फिर से दोहराई जाती है।

इस स्थिति को हल करने के लिए, यह आवश्यक है कि इस कार्यक्षमता को रखने के लिए, एक मध्यवर्ती दायित्व बनाना है। यानी, dll के बजाय, lib करें। फिर फिर से एक स्थिर चर रहेगा।

निष्कर्ष : स्थैतिक पुस्तकालयों में स्थिर चर का उपयोग करते समय, आपको यह सुनिश्चित करने की आवश्यकता है कि निष्पादन योग्य मॉड्यूल एक दूसरे से सांख्यिकीय रूप से लिंक न हों।

कभी-कभी निर्भरता के सरलीकरण से समस्या हल नहीं होती है। उदाहरण के लिए, एक क्लास को स्टैटिक लाइब्रेरी में लागू किया जाता है और इसमें एक निश्चित स्टैटिक इंस्टेंस काउंटर होता है। यह स्थिर पुस्तकालय दो अलग-अलग dll में जोड़ता है, इसलिए उनमें दो अलग-अलग काउंटर बनाए जाते हैं। इस स्थिति में, स्थिर लायब्रेरी को डायनेमिक एक (dll) में बदलकर समस्या हल हो जाती है। तदनुसार, अन्य दो dll नए dll को गतिशील रूप से लिंक करते हैं। तब स्टेटिक वैरिएबल केवल एक ही dll में होगा (एक में जिस पर काउंटर को लागू किया गया है)।

सभी कोड github से लिए जा सकते हैं।

पीएस मैंने बहुत सारी चीजें लिखी हैं, शायद बिल्कुल सही नहीं ... मुझे सलाह और टिप्पणी करने में खुशी होगी।