पुस्तकालय कोड के कार्यान्वयन की सूक्ष्मता। भाग दो

पिछले भाग में , हमने एक विधि का वर्णन किया है जिसके द्वारा आप अन्य नामस्थानों से सहायक वर्गों और वर्गों का उपयोग करते समय कोड की मात्रा को कम कर सकते हैं।

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

लाइब्रेरी फ़ाइलों को व्यवस्थित करने के लिए दृष्टिकोण

शुरू करने के लिए, हम तय करेंगे कि हम पुस्तकालयों के बारे में बात करेंगे, जिनमें से सभी कोड हेडर फ़ाइलों के रूप में दिए गए हैं। ऐसे पुस्तकालयों में एक फ़ाइल संरचना बनाते समय, कई नियमों का पालन किया जाता है। उन सभी को "मानक" नहीं कहा जा सकता है, लेकिन मौजूदा पुस्तकालयों में प्रस्तुत नियमों का आवेदन ऐसी दुर्लभ घटना नहीं है।

1) लाइब्रेरी हेडर फाइलें आमतौर पर एक अलग फ़ोल्डर में रखी जाती हैं ।

फ़ोल्डर नाम में लाइब्रेरी का नाम या लाइब्रेरी में उपयोग किए जाने वाले नामस्थान शामिल हैं। यह आपको उपयोगकर्ता कोड में लाइब्रेरी के उपयोग को "दस्तावेज" करने की अनुमति देता है:

#include <boost/array.hpp> #include <boost/scoped_ptr.hpp> 

2) "उपयोगकर्ता" प्रकार वाली फाइलें और कार्यान्वयन विवरण प्रदान करने वाली फाइलें अधिमानतः विभिन्न फ़ोल्डरों में रखी जानी चाहिए ।

"उपयोगकर्ता-परिभाषित" प्रकारों को लाइब्रेरी द्वारा परिभाषित प्रकारों के रूप में समझा जाता है और उपयोगकर्ता को उनके कोड में उपयोग के लिए प्रदान किया जाता है।

पुस्तकालय डेवलपर द्वारा इस नियम के आवेदन से पुस्तकालय उपयोगकर्ता को उन फ़ाइलों को आसानी से निर्धारित करने की अनुमति मिलती है जिन्हें उन्हें संबंधित दस्तावेज को पढ़े बिना अपनी परियोजना में शामिल करने की आवश्यकता होती है।
उदाहरण के लिए, कुछ बूस्ट लाइब्रेरी विस्तार से सबफ़ोल्डर में कार्यान्वयन फ़ाइलों की मेजबानी करते हैं।

3) पुस्तकालय के प्रत्येक वर्ग के लिए, एक ही नाम वाली एक अलग फ़ाइल अक्सर बनाई जाती है ।

यह दृष्टिकोण पुस्तकालय उपयोगकर्ता को आसानी से इसकी संरचना को समझने की अनुमति देता है, और डेवलपर अपने पुस्तकालय में कक्षाओं के माध्यम से नेविगेशन की आसानी प्रदान करता है।

4) लाइब्रेरी की फाइलें आत्मनिर्भर होनी चाहिए ।

मूल रूप से, यह उन फाइलों पर लागू होता है जिनमें "उपयोगकर्ता" प्रकार परिभाषित किए गए हैं और जो लाइब्रेरी उपयोगकर्ता अपने प्रोग्राम या किसी अन्य लाइब्रेरी में #include का उपयोग करके जोड़ता है।

आप इस नियम के बारे में जी। सटर और ए। अलेक्जेंड्रेस्कु (नियम 23) की पुस्तक "C ++ प्रोग्रामिंग स्टैंडर्ड" में अधिक पढ़ सकते हैं।

परीक्षण पुस्तकालय का विवरण

इसके बाद, मान लीजिए कि हमें कुछ SomeLib लाइब्रेरी को लागू करने की आवश्यकता है। इस लाइब्रेरी को उपयोगकर्ता को A_1 , A_2 और A_3 की कक्षाएं प्रदान करनी चाहिए जो कुछ कार्यक्षमता को लागू करते हैं। आंकड़े में हरा क्षेत्र पुस्तकालय का प्रतिनिधित्व करता है, लाल नाम स्थान का प्रतिनिधित्व करता है, और नीला उपयोगकर्ता को प्रदान की जाने वाली कक्षाओं का प्रतिनिधित्व करता है।



SomeLib लाइब्रेरी को STL लाइब्रेरी पर निर्भर रहने दें और इसमें सहायक कक्षाएं I_1 और I_2 हैं जो उपयोगकर्ता के लिए "अदृश्य" हैं, जो आकृति में नारंगी में दिखाए गए हैं। तीर दूसरों पर कक्षाओं की निर्भरता का संकेत देते हैं। उदाहरण के लिए, क्लास A_1 , कक्षाओं की सूची , वेक्टर और I_1 पर निर्भर करता है। इस मामले में, वर्ग की निर्भरता का अर्थ है उसके डेटा, सदस्य कार्यों या इन कार्यों को लागू करने में उनके द्वारा अन्य वर्गों का उपयोग।



मान लीजिए कि लाइब्रेरी को हेडर फ़ाइलों के रूप में आपूर्ति की जाती है और इसमें config.hpp होता है, जो कुछ "कंट्रोल" संरचनाओं का वर्णन करता है, एक फाइल के रूप में।

तो यहाँ हम चलते हैं ...

प्रस्तुत नियमों का उपयोग करके एक परीक्षण पुस्तकालय को लागू करना

पुस्तकालय को लागू करते समय, हम पिछले भाग में वर्णित मानक दृष्टिकोण का उपयोग करेंगे। हम लायब्रेरी के नामस्थान some_lib में यूजर क्लासेस और नेस्टेड नेमस्पेस नाम की उपयोगिता क्लासेस लगा देंगे ।

लाइब्रेरी some_lib फ़ोल्डर में स्थित होगी। इस फ़ोल्डर में ए _ * होगा। "उपयोगकर्ता" प्रकारों का वर्णन करने वाली एचपीपी फाइलें । फ़ाइलें I _ *। Hpp , उपयोगिता वर्ग युक्त, को निहित फ़ोल्डर में रखा जाएगा।



अब आप कार्यान्वयन शुरू कर सकते हैं। हम कोडिंग प्रक्रिया का विवरण छोड़ते हैं और तुरंत परिणामों के लिए आगे बढ़ते हैं।

कुछ_लिब / इम्पैक्ट / config.hpp फाइल करें

 #ifndef SOME_LIB__IMPL__CONFIG_HPP #define SOME_LIB__IMPL__CONFIG_HPP #if defined(_MSC_VER) //... #elif defined(__GNUC__) //... #else //... #endif #endif 

कुछ_लिब / इप / I_1.hpp फ़ाइल करें

 #ifndef SOME_LIB__IMPL__I_1_HPP #define SOME_LIB__IMPL__I_1_HPP #include <vector> #include <some_lib/impl/config.hpp> namespace some_lib { namespace impl { class I_1 { public: void func( std::vector<int> const& ); private: // - }; }} #endif 

कुछ_लिब / इप / I_2.hpp फ़ाइल

 #ifndef SOME_LIB__IMPL__I_2_HPP #define SOME_LIB__IMPL__I_2_HPP #include <vector> #include <some_lib/impl/config.hpp> namespace some_lib { namespace impl { class I_2 { public: //  private: std::vector<int> data_; }; }} #endif 

कुछ_लिब / A_1.hpp फ़ाइल करें

 #ifndef SOME_LIB__A_1_HPP #define SOME_LIB__A_1_HPP #include <list> #include <vector> #include <some_lib/impl/config.hpp> #include <some_lib/impl/I_1.hpp> namespace some_lib { class A_1 { public: //  private: impl::I_1 a_; std::list<int> data_; std::vector<int> another_data_; }; } #endif 

कुछ_लिब / A_2.hpp फ़ाइल करें

 #ifndef SOME_LIB__A_2_HPP #define SOME_LIB__A_2_HPP #include <string> #include <some_lib/impl/config.hpp> #include <some_lib/impl/I_2.hpp> namespace some_lib { class A_2 { public: A_2( std::string const& ); private: impl::I_2 a_; }; } #endif 

कुछ_लिब / A_3.hpp फ़ाइल करें

 #ifndef SOME_LIB__A_3_HPP #define SOME_LIB__A_3_HPP #include <string> #include <some_lib/impl/config.hpp> #include <some_lib/impl/I_2.hpp> #include <some_lib/A_2.hpp> namespace some_lib { class A_3 { public: A_3( std::string const& ); void func( A_2& ); private: impl::I_2 a_; std::string name_; }; } #endif 

उपयोगकर्ता अब एक या अधिक हेडर फ़ाइलों को संलग्न करके हमारे पुस्तकालय का उपयोग कर सकता है।

 #include <some_lib/A_1.hpp> #include <some_lib/A_2.hpp> #include <some_lib/A_3.hpp> 

टेस्ट लाइब्रेरी कार्यान्वयन विचार

कोड को थोड़ा कम करने के लिए, #ifndef , #define , #endif के माध्यम से शामिल करने और लागू करने के मानक "अभिभावकों" के बजाय, आप हेडर फ़ाइलों में एक बार #pragma का उपयोग कर सकते हैं। लेकिन यह विधि सभी कंपाइलरों पर काम नहीं करती है और इसलिए, हमेशा लागू नहीं होती है।

हमारे पुस्तकालय में तत्वों के बीच कनेक्शन की अपेक्षाकृत सरल योजना है। लाइब्रेरी के डेवलपर अधिक जटिल निर्भरता को लागू करने के लिए क्या भुगतान करता है, यह कल्पना करना मुश्किल नहीं है।

यह एक और दिलचस्प बात ध्यान देने योग्य है। जब केवल एक हेडर फ़ाइल some_lib / A_3.hpp शामिल होती है, तो उपयोगकर्ता वास्तव में आधे से अधिक पुस्तकालय (अधिक सटीक, 4/6 स्रोत फ़ाइलें) जोड़ता है।

और अगर आप अब अपने आप से सवाल पूछते हैं: क्या पुस्तकालय उपयोगकर्ता के लिए अपने व्यक्तिगत तत्वों को जोड़ने की क्षमता को लागू करना वास्तव में इतना आवश्यक है?

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

मान लीजिए कि इस प्रश्न का उत्तर "नहीं" है यहीं से शुरू होती है मस्ती ...

एकल माउंट बिंदु का उपयोग करके एक परीक्षण पुस्तकालय को लागू करना

लाइब्रेरी को जोड़ने के लिए उपयोगकर्ता को अब केवल एक लाइन कोड की आवश्यकता है:

 #include <some_lib/include.hpp> 

अब लाइब्रेरी डेवलपर द्वारा लागू किए जा सकने वाले कार्यान्वयन क्षणों पर ध्यान दें:
1) चूंकि लाइब्रेरी के लिए केवल एक कनेक्शन बिंदु है ( some_lib / शामिल.hpp फ़ाइल ), लाइब्रेरी डेवलपर को शामिल करने के सभी "गार्ड" से छुटकारा मिल सकता है, पूरे पुस्तकालय के कनेक्शन फ़ाइल में एक को छोड़कर।
2) एक "कस्टम" वर्ग या कार्यान्वयन तत्व वर्ग की प्रत्येक फ़ाइल को अब निर्भर तत्वों से युक्त फ़ाइल समावेशन शामिल करने की आवश्यकता नहीं है।
3) "काम" नामस्थानों का उपयोग प्रत्येक फ़ाइल में नामस्थानों की आवश्यकता को समाप्त करता है।

चूंकि लाइब्रेरी को उपयोगकर्ता से जोड़ने के लिए केवल एक फ़ाइल है, आप लाइब्रेरी फ़ाइलों की संरचना की समीक्षा कर सकते हैं।



पुस्तकालय कार्यान्वयन अब इस तरह दिख सकता है:

कुछ फ़ाइल दर्ज करें / शामिल करें

 #ifndef SOME_LIB__INCLUDE_HPP #define SOME_LIB__INCLUDE_HPP #include <list> #include <vector> #include <string> #include <some_lib/private/config.hpp> namespace z_some_lib { using namespace std; //  // using std::list; // using std::vector; // using std::string; #include <some_lib/private/I_1.hpp> #include <some_lib/private/I_2.hpp> #include <some_lib/public/A_1.hpp> #include <some_lib/public/A_2.hpp> #include <some_lib/public/A_3.hpp> } namespace some_lib { using z_some_lib::A_1; using z_some_lib::A_2; using z_some_lib::A_3; } #endif 

फ़ाइल कुछ_लिब / निजी / config.hpp

 #if defined(_MSC_VER) //... #elif defined(__GNUC__) //... #else //... #endif 

कुछ_लिब / निजी / I_1.hpp फ़ाइल करें

 class I_1 { public: void func( vector<int> const& ); private: // - }; 

कुछ_लिब / निजी / I_2.hpp फ़ाइल करें

 class I_2 { public: //  private: vector<int> data_; }; 

कुछ_लिब / सार्वजनिक / A_1.hpp फ़ाइल करें

 class A_1 { public: //  private: I_1 a_; list<int> data_; vector<int> another_data_; }; 

फ़ाइल कुछ_लिब / सार्वजनिक / A_2.hpp

 class A_2 { public: A_2( string const& ); private: I_2 a_; }; 

फ़ाइल कुछ_लिब / सार्वजनिक / A_3.hpp

 class A_3 { public: A_3( string const& ); void func( A_2& ); private: I_2 a_; string name_; }; 

निष्कर्ष

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

और यदि आप प्रस्तुत योजना को करीब से देखते हैं, अर्थात्, कुछ परिचित की भावना। लेकिन यह अब नहीं है ...