C ++ में आंतरिक और बाहरी लिंकिंग

सभी को शुभ दिन!

हम आपके लिए एक दिलचस्प लेख का अनुवाद प्रस्तुत करते हैं जो पाठ्यक्रम "सी ++ डेवलपर" के हिस्से के रूप में आपके लिए तैयार किया गया है। हम आशा करते हैं कि यह आपके लिए उपयोगी होगा, साथ ही साथ हमारे श्रोताओं के लिए भी।

चलो चलते हैं।

क्या आपने कभी आंतरिक और बाहरी संचार की शर्तों का सामना किया है? यह जानना चाहते हैं कि बाहरी कीवर्ड का उपयोग किस लिए किया जाता है, या कुछ स्थैतिक की घोषणा वैश्विक दायरे को कैसे प्रभावित करती है? फिर यह लेख आपके लिए है।

संक्षेप में

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

• गैर-कॉस्ट ग्लोबल वैरिएबल - बाहरी बंधन;
• कास्ट ग्लोबल वैरिएबल - आंतरिक बाध्यकारी;
• कार्य - बाहरी लिंकिंग।

मूल बातें

पहले, आइए बंधन पर चर्चा करने के लिए आवश्यक दो सरल अवधारणाओं के बारे में बात करें।

• एक घोषणा और एक परिभाषा के बीच का अंतर;
• प्रसारण इकाइयाँ।

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

घोषणा वी.एस. परिभाषा

हम संक्षेप में एक घोषणा और एक प्रतीक परिभाषा के बीच के अंतर पर चर्चा करते हैं: एक घोषणा (या घोषणा) एक विशिष्ट प्रतीक के अस्तित्व के बारे में संकलक को बताती है, और उन मामलों में इस प्रतीक तक पहुंच की अनुमति देता है जिन्हें सटीक स्मृति पते या प्रतीक भंडारण की आवश्यकता नहीं होती है। परिभाषा संकलक को बताती है कि फ़ंक्शन के शरीर में क्या निहित है या चर को कितनी मेमोरी आवंटित करने की आवश्यकता है।

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

कार्यों

एक फ़ंक्शन को परिभाषित करने और घोषित करने के बीच का अंतर बहुत स्पष्ट है।

int f(); //  int f() { return 42; } //  

चर

चर के साथ, यह थोड़ा अलग है। घोषणा और परिभाषा आमतौर पर साझा नहीं की जाती है। मुख्य बात यह है:

 int x; 

न केवल x घोषणा करता है, बल्कि इसे परिभाषित भी करता है। यह डिफ़ॉल्ट कंस्ट्रक्टर इंट के लिए कॉल के कारण है। (C ++ में, Java के विपरीत, सरल प्रकारों (जैसे int) का निर्माता डिफ़ॉल्ट रूप से मान को 0 से प्रारंभ नहीं करता है। ऊपर के उदाहरण में, x संकलक द्वारा आवंटित मेमोरी एड्रेस में पड़े किसी कचरे के बराबर होगा)।

लेकिन आप extern कीवर्ड का उपयोग करके स्पष्ट रूप से परिवर्तनशील घोषणा और उसकी परिभाषा को अलग कर सकते हैं।

 extern int x; //  int x = 42; //  

हालाँकि, जब ऐलान के लिए extern को शुरू और जोड़ना, अभिव्यक्ति एक परिभाषा में बदल जाता है और extern कीवर्ड बेकार हो जाता है।

 extern int x = 5; //   ,   int x = 5; 

विज्ञापन पूर्वावलोकन

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

उदाहरण

मान लें कि हमारे पास f के लिए एक फ़ंक्शन डिक्लेरेशन (जिसे एक प्रोटोटाइप कहा जाता है) है, जो वैल्यू के Class से टाइप Class का ऑब्जेक्ट लेता है:

 // file.hpp void f(Class object); 

तुरंत Class की परिभाषा को शामिल करें - भोली। लेकिन जब से हमने सिर्फ f घोषित किया f , कंपाइलर को Class घोषणा देना काफी है। इस प्रकार, कंपाइलर अपने प्रोटोटाइप द्वारा फ़ंक्शन को पहचान सकेगा, और हम फाइल की निर्भरता से छुटकारा पा सकेंगे।

 // file.hpp class Class; void f(Class object); 

मान लीजिए कि file.hpp 100 अन्य फाइलों में समाहित है। और मान लें कि हम क्लास की परिभाषा को क्लास में बदल देते हैं। यदि आप class.hpp को file.hpp, file.hpp में जोड़ते हैं और इसमें मौजूद सभी 100 फाइलों को recompiled करना होगा। कक्षा की प्रारंभिक घोषणा के लिए धन्यवाद, पुन: प्राप्ति की आवश्यकता वाली एकमात्र फाइलें class.hpp और file.hpp होंगी (यह मानते हुए कि एफ वहाँ परिभाषित है)।

उपयोग की आवृत्ति

एक घोषणा और एक परिभाषा के बीच एक महत्वपूर्ण अंतर यह है कि एक प्रतीक को कई बार घोषित किया जा सकता है, लेकिन केवल एक बार परिभाषित किया गया है। इसलिए आप एक फ़ंक्शन या वर्ग को जितनी बार चाहें उतनी बार पूर्व-घोषित कर सकते हैं, लेकिन केवल एक ही परिभाषा हो सकती है। इसे नियम की एक परिभाषा कहा जाता है। C ++ में, निम्नलिखित कार्य करता है:

 int f(); int f(); int f(); int f(); int f(); int f(); int f() { return 5; } 

और यह काम नहीं करता है:

 int f() { return 6; } int f() { return 9; } 

प्रसारण इकाइयाँ

प्रोग्रामर आमतौर पर हेडर फाइलों और कार्यान्वयन फाइलों के साथ काम करते हैं। लेकिन संकलक नहीं - वे अनुवाद इकाइयों (संक्षिप्त इकाइयों के लिए, लघु - टीयू) के साथ काम करते हैं, जिन्हें कभी-कभी संकलन इकाइयाँ कहा जाता है। इस तरह की एक इकाई की परिभाषा काफी सरल है - इसकी प्रारंभिक प्रसंस्करण के बाद संकलक को हस्तांतरित कोई भी फ़ाइल। सटीक होने के लिए, यह एक्सटेंशन मैक्रो प्रीप्रोसेसर के काम के परिणामस्वरूप प्राप्त की गई फ़ाइल है, जिसमें स्रोत कोड भी शामिल है, जो #ifndef और #ifndef अभिव्यक्तियों पर निर्भर करता है, और सभी #include फ़ाइलों की कॉपी-पेस्ट।

निम्नलिखित फाइलें उपलब्ध हैं:

header.hpp:

 #ifndef HEADER_HPP #define HEADER_HPP #define VALUE 5 #ifndef VALUE struct Foo { private: int ryan; }; #endif int strlen(const char* string); #endif /* HEADER_HPP */ 

program.cpp:

 #include "header.hpp" int strlen(const char* string) { int length = 0; while(string[length]) ++length; return length + VALUE; } 

प्रीप्रोसेसर निम्न अनुवाद इकाई का उत्पादन करेगा, जिसे बाद में संकलक के पास भेज दिया जाता है:

 int strlen(const char* string); int strlen(const char* string) { int length = 0; while(string[length]) ++length; return length + 5; } 

संचार

मूल बातें पर चर्चा करने के बाद, आप संबंध शुरू कर सकते हैं। सामान्य तौर पर, संचार फ़ाइलों को संसाधित करते समय लिंकर के लिए वर्णों की दृश्यता होती है। संचार बाहरी या आंतरिक हो सकता है।

बाहरी संचार

जब एक प्रतीक (चर या फ़ंक्शन) का बाहरी संबंध होता है, तो यह अन्य फ़ाइलों के लिंकर्स को दिखाई देता है, अर्थात, "विश्व स्तर पर" दृश्यमान, सभी अनुवाद इकाइयों के लिए सुलभ। इसका मतलब यह है कि आपको इस तरह के एक प्रतीक को एक अनुवाद इकाई की एक विशिष्ट जगह में परिभाषित करना चाहिए, आमतौर पर कार्यान्वयन फ़ाइल (.c / .cpp) में, ताकि इसकी केवल एक दृश्य परिभाषा हो। यदि आप एक साथ प्रतीक को उसी समय परिभाषित करने का प्रयास करते हैं जब प्रतीक घोषित किया जाता है, या यदि आप परिभाषा को घोषणा के लिए फ़ाइल में रखते हैं, तो आप लिंकर को नियंत्रित करते हैं। एक से अधिक कार्यान्वयन फ़ाइल में फ़ाइल जोड़ने का प्रयास करने से एक से अधिक अनुवाद इकाई में परिभाषा जोड़ने की ओर जाता है - आपका लिंकर रो जाएगा।

C और C ++ (स्पष्ट रूप से) में बाहरी कीवर्ड घोषित करता है कि एक चरित्र का बाहरी संबंध है।

 extern int x; extern void f(const std::string& argument); 

दोनों पात्रों का बाहरी संबंध है। यह ऊपर उल्लेख किया गया था कि कॉन्स्टेबल ग्लोबल वेरिएबल्स में डिफ़ॉल्ट रूप से आंतरिक बाइंडिंग होती है, गैर-कॉस्ट ग्लोबल वैरिएबल्स में बाहरी बाइंडिंग होती है। इसका मतलब है कि इंट x; - एक्स के रूप में एक ही एक्स ?, सही? वास्तव में नहीं। इंट x; वास्तव में एक्स एक्सट्रीम एक्सट्रीम के अनुरूप; (एक्स / एक्स के बाद से सबसे अप्रिय पार्सिंग (सबसे अप्रिय पार्सिंग) से बचने के लिए सार्वभौमिक / ब्रैकेट इनिशियलाइज़ेशन सिंटैक्स का उपयोग करना); न केवल घोषित करता है, बल्कि एक्स को भी परिभाषित करता है। इसलिए, एक्स को एक्सटर्नल न जोड़ें; बाहरी रूप से घोषित करते समय एक चर को परिभाषित करना उतना ही बुरा है:

 int x; //   ,   extern int x{}; //      . extern int x; //      ,   

खराब उदाहरण

चलिए file.hpp में बाहरी लिंक के साथ एक फ़ंक्शन f घोषित करते हैं और इसे वहां परिभाषित करते हैं:

 // file.hpp #ifndef FILE_HPP #define FILE_HPP extern int f(int x); /* ... */ int f(int) { return x + 1; } /* ... */ #endif /* FILE_HPP */ 

कृपया ध्यान दें कि आपको यहां बाहरी जोड़ने की आवश्यकता नहीं है, क्योंकि सभी कार्य स्पष्ट रूप से बाहरी हैं। घोषणा और परिभाषा को अलग करने की भी आवश्यकता नहीं है। तो चलो इसे इस तरह से फिर से लिखें:

 // file.hpp #ifndef FILE_HPP #define FILE_HPP int f(int) { return x + 1; } #endif /* FILE_HPP */ 

इस तरह के कोड को इस लेख को पढ़ने से पहले, या शराब या भारी पदार्थों के प्रभाव में पढ़ने के बाद लिखा जा सकता है (उदाहरण के लिए, दालचीनी रोल)।

आइए देखें कि यह इसके लायक क्यों नहीं है। अब हमारे पास दो कार्यान्वयन फाइलें हैं: a.cpp और b.cpp, दोनों file.hpp में शामिल हैं:

 // a.cpp #include "file.hpp" /* ... */ 

 // b.cpp #include "file.hpp" /* ... */ 

अब संकलक को काम करने दें और ऊपर की दो कार्यान्वयन फाइलों के लिए दो अनुवाद इकाइयाँ बनाएँ (याद रखें कि #include शाब्दिक अर्थ है कॉपी / पेस्ट):

 // TU A, from a.cpp int f(int) { return x + 1; } /* ... */ 

 // TU B, from b.cpp int f(int) { return x + 1; } /* ... */ 

इस बिंदु पर, लिंकर हस्तक्षेप करता है (संकलन के बाद बंधन होता है)। लिंकर चरित्र f लेता है और एक परिभाषा के लिए खोज करता है। आज वह भाग्यशाली है, वह दो के रूप में कई पाता है! अनुवाद इकाई ए में एक, बी में अन्य लिंकर खुशी के साथ जमा देता है और आपको कुछ इस तरह बताता है:

 duplicate symbol __Z1fv in: /path/to/ao /path/to/bo 

लिंक करने वाले को एक f वर्ण के लिए दो परिभाषाएँ मिलती हैं। चूंकि f में एक बाहरी बंधन है, यह ए और बी दोनों को संसाधित करते समय लिंकर को दिखाई देता है। जाहिर है, यह एक परिभाषा के नियम का उल्लंघन करता है और एक त्रुटि का कारण बनता है। अधिक सटीक रूप से, यह एक डुप्लिकेट प्रतीक त्रुटि का कारण बनता है, जिसे आप एक अपरिभाषित प्रतीक त्रुटि से कम नहीं प्राप्त करेंगे जो तब होता है जब आप एक प्रतीक घोषित करते हैं, लेकिन इसे परिभाषित करना भूल जाते हैं।

के उपयोग

बाहरी चर घोषित करने का एक मानक उदाहरण वैश्विक चर है। मान लीजिए आप एक सेल्फ-बेकिंग केक पर काम कर रहे हैं। निश्चित रूप से केक से जुड़े वैश्विक चर हैं जो आपके कार्यक्रम के विभिन्न हिस्सों में उपलब्ध होने चाहिए। मान लें कि आपके केक के अंदर एक खाद्य सर्किट की घड़ी की आवृत्ति है। यह मूल्य स्वाभाविक रूप से सभी चॉकलेट इलेक्ट्रॉनिक्स के तुल्यकालिक संचालन के लिए विभिन्न भागों में आवश्यक है। इस तरह के वैश्विक चर को घोषित करने का सी (तरीका) एक मैक्रो के रूप में है:

 #define CLK 1000000 

एक सी ++ प्रोग्रामर जो मैक्रोज़ से घृणा करता है, वास्तविक कोड को बेहतर लिखेगा। उदाहरण के लिए, यह:

 // global.hpp namespace Global { extern unsigned int clock_rate; } // global.cpp namespace Global { unsigned int clock_rate = 1000000; } 

(एक आधुनिक C ++ प्रोग्रामर जुदाई शाब्दिक का उपयोग करना चाहेगा: अहस्ताक्षरित int clock_rate = 1'000'000);

आंतरिक संचार

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

एक परस्पर प्रतीक को घोषित करने के लिए, स्थिर कीवर्ड C और C ++ में मौजूद है। यह उपयोग वर्गों और कार्यों (या, सामान्य रूप से, किसी भी ब्लॉक में) का उपयोग करने से अलग है।

उदाहरण

यहाँ एक उदाहरण है:

header.hpp:

 static int variable = 42; 

file1.hpp:

 void function1(); 

file2.hpp:

 void function2(); 

file1.cpp:

 #include "header.hpp" void function1() { variable = 10; } 

file2.cpp:

 #include "header.hpp" void function2() { variable = 123; } 

main.cpp:

 #include "header.hpp" #include "file1.hpp" #include "file2.hpp" #include <iostream> auto main() -> int { function1(); function2(); std::cout << variable << std::endl; } 

हैडर.ह्प्प सहित प्रत्येक अनुवाद इकाई को, इसके आंतरिक कनेक्शन के कारण, चर की एक अनूठी प्रति मिलती है। तीन अनुवाद इकाइयाँ हैं:

1. file1.cpp
2. file2.cpp
3. main.cpp

जब function1 कहा जाता है, तो file1.cpp वैरिएबल की एक कॉपी को मान मिलता है। जब function2 को कॉल किया जाता है, तो file2.cpp वैरिएबल की एक कॉपी का मान 123 हो जाता है। हालाँकि, main.cpp में दिया गया मान नहीं बदलता है और 42 के बराबर रहता है।

अनाम नामस्थान

C ++ में, एक या अधिक आंतरिक रूप से जुड़े वर्णों को घोषित करने का एक और तरीका है: अनाम नाम स्थान। ऐसा स्थान सुनिश्चित करता है कि इसके अंदर घोषित वर्ण केवल वर्तमान अनुवाद इकाई में दिखाई दे रहे हैं। अनिवार्य रूप से, यह कई स्थिर चरित्रों को घोषित करने का एक तरीका है। कुछ समय के लिए, आंतरिक नाम से जुड़े चरित्र को घोषित करने के लिए स्थैतिक कीवर्ड का उपयोग अनाम नामस्थान के पक्ष में छोड़ दिया गया था। हालांकि, आंतरिक संचार के साथ एक चर या फ़ंक्शन घोषित करने की सुविधा के कारण उन्होंने फिर से इसका उपयोग करना शुरू कर दिया। कुछ अन्य छोटे अंतर हैं जिन पर मैं ध्यान नहीं दूंगा।

किसी भी मामले में, यह है:

 namespace { int variable = 0; } 

करता है (लगभग) के रूप में एक ही बात:

 static int variable = 0; 

के उपयोग

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

हालांकि, आंतरिक संचार का उपयोग स्थानीय सहायक कार्यों के वैश्विक क्षेत्र से अनुवाद इकाई को छिपाने के लिए किया जा सकता है। मान लीजिए कि file1.hpp में एक foo हेल्पर फ़ंक्शन है जो आप file1.cpp में उपयोग करते हैं। उसी समय, आपके पास file2.hpp में foo फंक्शन होता है। पहली और दूसरी फू एक दूसरे से अलग हैं, लेकिन आप अन्य नामों के साथ नहीं आ सकते हैं। इसलिए, आप उन्हें स्थिर घोषित कर सकते हैं। यदि आप एक ही अनुवाद इकाई में file1.hpp और file2.hpp दोनों को नहीं जोड़ते हैं, तो यह एक-दूसरे से foo छिपाएगा। यदि ऐसा नहीं किया जाता है, तो उनका स्पष्ट रूप से एक बाहरी संबंध होगा और पहले फू की परिभाषा दूसरे की परिभाषा का सामना करेगी, जिससे एक परिभाषा के नियम का उल्लंघन करने के बारे में एक लिंकर त्रुटि हो सकती है।

अंत

आप हमेशा अपनी टिप्पणियों और / या प्रश्नों को यहां छोड़ सकते हैं या हमें एक खुले दिन पर जा सकते हैं।