🌜 👨‍👩‍👧‍👧 🖨️ C ++ 11 में एक अभ्यास के रूप में प्लगइन प्रणाली 🛀🏿 🧙🏾 🤦🏿

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

क्या यह इस तरह से कुछ लिखने या तैयार समाधान लेने के लिए समझ में आता है? पोस्ट इस प्रश्न का उत्तर प्रदान नहीं करता है। इस पोस्ट में "क्यों इसकी आवश्यकता है" विषय पर कोई दर्शन नहीं होगा।

कुछ ऐसा ही करने का प्रयास C ++ 03 में पहले से ही था। इसने एक घटक / प्लग-इन मॉडल विकसित किया जो प्रक्रिया के भीतर रहता है। मेरे लिए, इस समस्या को हल करना दिलचस्प है। 4.7.2 में, इस लेख की शुरुआत के समय जो कुछ भी मेरे लिए दिलचस्प था, वह पहले ही सामने आ चुका है, और यह इस (2013) वर्ष की शुरुआत है। और फिर मुझे C ++ 11 मिला ... एक दिशा में काम करने पर, दूसरे में घर पर। C ++ 11 के साथ खेलने के लिए, मैंने पुराने लेख से भाषा की नई विशेषताओं के साथ सामग्री को फिर से लिखने का फैसला किया। कुछ अर्थों में सी ++ में एक व्यायाम करने के लिए। लेकिन किसी कारण से, मैं छह महीने से अधिक समय तक लेख को अंत तक लाने में सक्षम नहीं था, और लेख ने ड्राफ्ट में झूठ बोला था। वह मिल गया, नेफ़थलीन को हिला दिया। क्या आया इस पर पढ़ा जा सकता है।

C ++ 11 का उपयोग करने के निर्णय के बारे में

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

परिचय और थोड़ा दर्शन

यहां यह थोड़ी बात होगी कि प्लग-इन सिस्टम या घटक मॉडल का यह कार्यान्वयन किन सिद्धांतों पर आधारित है और इसे क्यों चुना गया है, न कि दूसरे तरीके से। कुछ पानी डाला जाएगा: मेरे विचार। यदि आप इस तरह के दार्शनिकता में रुचि नहीं रखते हैं, तो साहसपूर्वक कार्यान्वयन के लिए आगे बढ़ें।

इंटरफेस और पहचानकर्ता

वर्णित विकास का आधार इंटरफेस के माध्यम से सिस्टम घटकों की बातचीत पर आधारित होगा। इस संदर्भ में एक इंटरफ़ेस को केवल शुद्ध आभासी तरीकों से युक्त C ++ संरचना के रूप में समझा जाना चाहिए। इंटरफ़ेस कुछ तार्किक इकाई होगी जिसके चारों ओर सब कुछ बनाया गया है।

महत्वपूर्ण मुद्दों में से एक हो सकता है - एक इंटरफ़ेस, कार्यान्वयन, मॉड्यूल और अन्य संस्थाओं के लिए पहचानकर्ता के रूप में क्या उपयोग किया जाए। पिछले लेख में, एक सी-स्ट्रिंग का उपयोग एक पहचानकर्ता के रूप में किया गया था, क्योंकि यह अधिक से अधिक विशिष्टता प्रदान करना संभव है यदि, उदाहरण के लिए, आप कुछ टूल द्वारा उत्पन्न यूआईडी का उपयोग करते हैं और पहचानकर्ता के रूप में एक स्ट्रिंग में अनुवाद किया जाता है। आप एक पहचानकर्ता के रूप में एक संख्यात्मक पहचानकर्ता का भी उपयोग कर सकते हैं। इस तरह के एक समाधान के साथ, विशिष्टता कमजोर होगी, लेकिन फायदे हैं - यह न्यूनतम, अधिक से अधिक प्रदर्शन पर है, जो स्पष्ट रूप से संख्याओं की तुलना में स्ट्रिंग्स की तुलना में अधिक कठिन है। एक संख्यात्मक पहचानकर्ता के मूल्य के रूप में, उदाहरण के लिए, एक स्ट्रिंग से CRC32 का उपयोग किया जा सकता है। मान लीजिए कि एक इब्से इंटरफ़ेस है और यह कॉमन नेमस्पेस में है। "Common.IBase" लाइन से CRC32 एक पहचानकर्ता बन सकता है। हां, यदि इंटरफ़ेस पहचानकर्ता अचानक कहीं से मेल खाता है, क्योंकि यह uuid नहीं है, तो आपको "खुश" डिबगिंग के लंबे घंटे मिलेंगे और रूसी भाषा के मजबूत पक्ष में महारत हासिल करने का एक अच्छा समय होगा। लेकिन अगर आपकी कोई महत्वाकांक्षा नहीं है कि आपके मॉडल का उपयोग वैश्विक प्रणालियों में दुनिया भर में किया जाएगा, तो लंबी डीबगिंग के साथ परिणाम की संभावना कम से कम है। कुछ कार्यालयों में मैंने अपने "शिल्प" को एमएस-कॉम की शैली में निपटाया, जिसमें संख्यात्मक मान एक पहचानकर्ता के रूप में उपयोग किए गए थे और ऊपर वर्णित समस्या पर ठोकर नहीं खाते थे, और ऐसी अफवाहें नहीं थीं कि किसी के पास भी थी। इसलिए, इस कार्यान्वयन में एक संख्यात्मक पहचानकर्ता का उपयोग किया जाएगा। प्रदर्शन के अलावा, इस तरह के एक समाधान से एक और सकारात्मक बिंदु है: आप संकलन के समय एक संख्यात्मक पहचानकर्ता के साथ बहुत सारी दिलचस्प चीजें कर सकते हैं, क्योंकि स्ट्रिंग को हेरफेर करने से टेम्पलेट पैरामीटर काम नहीं करेंगे, और यह संख्या के लिए आसान है। और यहां, सी ++ 11 के पहले प्लस का उपयोग किया जाएगा - यह कॉन्स्टैक्स है, जिसके साथ आप संकलन के समय हैश के मूल्यों की गणना कर सकते हैं।

क्रॉस-प्लेटफ़ॉर्म और भाषा का समर्थन

वर्णित मॉडल क्रॉस-प्लेटफॉर्म होगा। कुछ के पार वहाँ विकास में दिलचस्प बिंदुओं में से एक है। C ++ डेवलपर के लिए, सबसे समझ में आने वाले कार्यों में से एक क्रॉस-प्लेटफॉर्म का समर्थन करना है, लेकिन क्रॉस-संकलन से संबंधित कार्य कम आम हैं, क्योंकि एक कंपाइलर द्वारा आसानी से समर्थित होने पर दूसरे पर समर्थन नहीं किया जा सकता है। ऐसा एक उदाहरण संकलन के समय में अभिव्यक्ति के प्रकार की प्राप्ति को लागू करने के प्रयास के घोषणापत्र के कार्यान्वयन से पहले है। एक अच्छा उदाहरण BOOST_TYPEOF है। यदि आप BOOST_TYPEOF के "हुड के नीचे" देखते हैं, तो आपको लाठी और बैसाखी का एक बड़ा सेट मिलेगा, क्योंकि ऐसी चीज़ों को C ++ 03 का उपयोग करके लागू नहीं किया जा सकता था, लेकिन मुख्य रूप से एक विशेष संकलक की कुछ उन्नत सुविधाओं पर हल किया गया था। सी ++ 11 में भी, मानक पुस्तकालय का विस्तार हुआ, जिसने धाराओं, तुल्यकालन वस्तुओं आदि पर अपने स्वयं के आवरण लिखने से इनकार करना संभव बना दिया। हम डेवलपर्स के लिए मानक प्रकार के पुस्तकालय कार्यों के लिए एक विशेष धन्यवाद कह सकते हैं, क्योंकि उन्होंने कई मामलों में अपना कोड लिखने की आवश्यकता को समाप्त कर दिया है, और, सबसे महत्वपूर्ण बात, उन्होंने एसटी :: is_pod और अन्य जैसे तरीकों का कार्यान्वयन दिया है, जो मानक C ++ 03 टूल का उपयोग करके लागू किया जा सकता है संकलक एक्सटेंशन का उपयोग करना संभव नहीं था।

तृतीय-पक्ष पुस्तकालयों का उपयोग करें

तीसरे पक्ष के पुस्तकालयों के उपयोग को कम करने की इच्छा थी और यदि संभव हो, तो उनके उपयोग को शून्य तक कम करें। यह शुद्ध C ++ विकास होगा। अंतिम घटकों को लागू करते समय, किसी भी चीज का उपयोग कार्य के आधार पर किया जा सकता है, कोई भी पुस्तकालय, लेकिन यहां प्रस्तुत मॉडल स्वयं तृतीय-पक्ष पुस्तकालयों का उपयोग करने के अर्थ में शुद्ध होगा।

तीसरे पक्ष के पुस्तकालयों के उपयोग के लिए मेरा एक निश्चित रवैया है: परियोजना में पुस्तकालय का उपयोग न करें यदि इसकी कार्यक्षमता क्लाइंट कोड द्वारा सबसे अधिक संभव तरीके से उपयोग नहीं की जाती है। आपको Qt को केवल प्रोजेक्ट में नहीं खींचना चाहिए क्योंकि कुछ लोग QStrung और QList का उपयोग करना पसंद करते हैं। हां, मुझे ऐसी परियोजनाएं मिली हैं जिनमें कुछ पुस्तकालयों और रूपरेखाओं को केवल कुछ डेवलपर्स की आदत के कारण कुछ छोटे और महत्वहीन हिस्से का उपयोग करने के लिए कानों द्वारा खींचा गया था। सामान्य तौर पर, इस तरह के पुस्तकालयों के उपयोग को बढ़ावा देने के रूप में, क्यूटी, पोको और अन्य से इनकार नहीं किया जा सकता है, लेकिन उन्हें उस स्थान पर लागू किया जाना चाहिए, परियोजना में केवल तभी शामिल किया जाता है जब उनकी बहुत आवश्यकता होती है। चिड़ियाघर लगाना उचित नहीं है, इसलिए, परियोजना में विदेशी जानवरों के एक जोड़े को प्राप्त करें और अधिक नहीं :) ताकि परियोजना को 5-7 या उससे अधिक प्रकार की लाइनें न मिलें, जिनमें से 2-3 आपकी अपनी साइकिल हैं, और बाकी अन्य पुस्तकालयों से आए और एक कार्यान्वयन से दूसरे में कन्वर्टर्स का एक लिखित गुच्छा। नतीजतन, उपयोगी कार्य के बजाय विकसित कार्यक्रम, समान संस्थाओं के विभिन्न कार्यान्वयनों के बीच परिवर्तित करने में काफी ध्यान देने योग्य समय व्यतीत करता है।

बॉस ...

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

इंटरफ़ेस में न्यूनतम

अगले पुस्तकालय पर विचार करते समय मेरे लिए महत्वपूर्ण मानदंडों में से एक मानदंड पुस्तकालय के साथ काम शुरू करने और इसे कार्य के लिए स्थापित करने के लिए अधिक से अधिक उन्नत विकल्प प्रदान करने की गति है। यही है, पुस्तकालय को अपने उपयोगकर्ता को बहुत लंबे अनुष्ठान करने के लिए मजबूर नहीं करना चाहिए इससे पहले कि इसके उपयोग के साथ कुछ शुरू हो। लेकिन एक ही समय में, आवश्यकतानुसार, इसके समायोजन और अधिक कठिन कार्यों के अनुकूलन के लिए अधिक से अधिक अवसर प्राप्त करने का अवसर होना चाहिए। यानी प्रारंभ में, यहां आपके लिए "मुँहासे" बटन है, जिस पर क्लिक करके एक निश्चित टेम्पलेट के अनुसार कार्यों का एक निश्चित अनुक्रम किया जाता है, और यदि आवश्यक हो, तो यहां बटन और स्विच का एक नियंत्रण कक्ष है। यह विचार प्रस्तावित मॉडल में निहित में से एक था: प्रारंभिक चरणों में उपयोगकर्ता से जितना संभव हो सके छिपाएं। पुस्तकालयों के अंदर, कोड मनमाने ढंग से जटिल हो सकता है, लेकिन इसकी सभी जटिलता के साथ यह पुस्तकालय के उपयोग की अधिकतम आसानी को सही ठहराना चाहिए।

कार्यान्वयन के कई विरासत

इंटरनेट पर वास्तविकताओं की कई विरासत का आयोजन किया गया था और कई पवित्र युद्धों का संचालन किया गया था। मेरा मानना है कि मल्टीपल इनहेरिटेंस C ++ की खूबियों में से एक है। हां, कुछ जगहों पर उसके साथ समस्याएं हैं, लेकिन उसके बिना, आसानी से बाहर निकलना भी हमेशा संभव नहीं होता है। प्रत्येक सी ++ टूल को किसी भी तरह से लेने और उपयोग करने का इरादा नहीं है, क्योंकि यह मौजूद है, लेकिन जब आवश्यकता उत्पन्न होती है, तो एक उपकरण होता है।

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

यहां, निश्चित रूप से, आप सिस्टम के डिजाइन के बारे में काफी चर्चा कर सकते हैं, लेकिन वास्तविक अभ्यास सैद्धांतिक कोड डिजाइन के रूप में आदर्शवादी नहीं है।
एक बार एक साक्षात्कार में मैंने एक उम्मीदवार (एक युवा से दूर) के बारे में पूछा कि वह कई विरासत के बारे में क्या जानता है। जवाब कुछ इस तरह था: “हाँ, मुझे पता है कि वहाँ कई विरासत है और, ऐसा लगता है, वहाँ आभासी कई विरासत है, लेकिन यह बुरा है। मैं इसका इस्तेमाल कभी नहीं करता। और मैं उसके बारे में और कुछ नहीं कह सकता

यदि आप नई इकाइयां बनाना चाहते हैं, तो उन्हें तैयार संस्थाओं के क्यूब्स से इकट्ठा करना है, तो कई उत्तराधिकार सबसे उपयोगी तंत्रों में से एक है। और घटक मॉडल केवल पहले से मौजूद कुछ से टुकड़ों से कुछ नया बनाने के लिए विस्तारित होते हैं।

कार्यान्वयन

कोर

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

namespace Boss { struct IBase { BOSS_DECLARE_IFACEID("Boss.IBase") virtual ~IBase() {} BOSS_DECLARE_IBASE_METHODS() }; }

हम्म, एक आभासी विध्वंसक और मैक्रोज़ के एक जोड़े ... कई लोग कहेंगे: "मैक्रोज़ बुरे हैं!" हाँ, यह तब बुरा होता है जब वे प्रचुर मात्रा में होते हैं और कहीं भी लागू होते हैं। कम मात्रा में और केवल यदि आवश्यक हो तो उपयोगी हो सकता है, क्योंकि फार्माकोलॉजी में जहर - खुराक के आधार पर मारता है और इलाज करता है।

BOSS_DECLARE_IFACEID

 #define BOSS_DECLARE_IFACEID(ifaceid_) \ static constexpr Boss::InterfaceId const GetInterfaceId() \ { \ return Boss::Crc32(ifaceid_); \ }

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

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

Crc32 गणना को लागू करने के लिए, आपको कुछ डेटा तालिका की आवश्यकता होती है जो आसानी से इंटरनेट पर पाई जा सकती है। इसका उपयोग करते हुए, crc32 को लगभग इस तरह पढ़ा जा सकता है:

 namespace Boss { namespace Private { template <typename T> struct Crc32TableWrap { static constexpr uint32_t const Table[256] = { 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, ... etc }; }; typedef Crc32TableWrap<EmptyType> Crc32Table; template<int const I> inline constexpr std::uint32_t Crc32Impl(char const *str) { return (Crc32Impl < I - 1>(str) >> 8) ^ Crc32Table::Table[(Crc32Impl< I - 1>(str) ^ str[I]) & 0x000000FF]; } template<> inline constexpr std::uint32_t Crc32Impl<-1>(char const *) { return 0xFFFFFFFF; } } template <std::size_t N> inline constexpr unsigned Crc32(char const (&str)[N]) { return (Private::Crc32Impl<sizeof(str) - 2>(str) ^ 0xFFFFFFFF); } }

तालिका एक संरचना में क्यों लिपटी है, और यहां तक कि एक टेम्पलेट में भी क्यों? डेटा परिभाषा के साथ एक cpp फ़ाइल से छुटकारा पाने के लिए, अर्थात्। सब कुछ केवल शामिल फ़ाइल में है और शामिल फ़ाइलों में स्थिर डेटा के आकर्षण के बिना।

Crc32 की गणना, पहचानकर्ता उत्पन्न। अब इस बात पर विचार करने के लिए कि दूसरा मैक्रो के नीचे क्या है:

BOSS_DECLARE_IBASE_METHODS

 #define BOSS_DECLARE_IBASE_METHODS() \ virtual Boss::UInt BOSS_CALL AddRef() = 0; \ virtual Boss::UInt BOSS_CALL Release() = 0; \ virtual Boss::RetCode BOSS_CALL QueryInterface(Boss::InterfaceId ifaceId, Boss::Ptr *iface) = 0;

हालांकि! वास्तव में एक संरचना में तीन तरीकों को लेना और रखना असंभव था? मैक्रो क्यों? और भारत में रिश्तेदारों की उपस्थिति के मुद्दे को खत्म करें ... लेकिन चूंकि कई उत्तराधिकार की अस्वीकृति नहीं है और इसके अलावा, इस मॉडल में बहुत स्वागत है, ताकि संकलक की चिंताओं को शांत किया जा सके कि उसे समझ में नहीं आता कि विरासत की कौन सी शाखा लेनी है। मैक्रो के तहत वर्णित विधियों में, इस मैक्रो का उपयोग कई और स्थानों पर किया जाएगा।

रेफरेंस काउंटिंग के माध्यम से ऑब्जेक्ट लाइफटाइम मैनेजमेंट लागू किया जाता है। IBase इंटरफ़ेस फ़ंक्शंस में संदर्भ काउंटर के साथ काम करने के तरीके और किसी ऑब्जेक्ट से इंटरफ़ेस के लिए अनुरोध करने की विधि शामिल है।

उपयोगकर्ता इंटरफ़ेस परिभाषा उदाहरण:

 struct IFace : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace") virtual void BOSS_CALL Mtd() = 0; };

लगभग सब कुछ स्पष्ट है: इंटरफ़ेस, इसके तरीकों की घोषणा, एक पहचानकर्ता की परिभाषा। लेकिन सिर्फ इब्से से विरासत में क्यों नहीं?

दूसरा उदाहरण उपयोगकर्ता इंटरफ़ेस है, ताकि आगे स्पष्टीकरण स्पष्ट हो:

 struct IFace1 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace1") virtual void BOSS_CALL Mtd1() = 0; }; struct IFace2 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace2") virtual void BOSS_CALL Mtd2() = 0; }; struct IFace3 : Boss::Inherit<IFace1, IFace2> { BOSS_DECLARE_IFACEID("IFace3") virtual void BOSS_CALL Mtd3() = 0; };

अब सब कुछ पता चला है? नहीं? यह सरल है: एकाधिक वंशानुक्रम की उपस्थिति में, यहां तक कि केवल इंटरफेस को किसी तरह से क्वैरीइंटरफेस लागू करते समय सही की तलाश में उन्हें "बायपास" करने में सक्षम होना चाहिए। मामला थोड़ा गूढ़ है, लेकिन कभी-कभी मैं इस पर आ गया। मान लीजिए कि आपके पास IFace3 के लिए एक संकेतक है, तो यह स्पष्ट है कि आप इसके आधार वर्गों के सभी तरीकों को यहां जगह दे सकते हैं। और यदि आप इसे किसी अन्य फ़ंक्शन को पास करते हैं, तो अधिक सामान्यीकृत, जो हमेशा कुछ इंटरफ़ेस से IFace1 या IFace2 का अनुरोध करता है, जरूरी नहीं कि इस तरह की विरासत संरचना के साथ हो, तो यह अब C ++ तंत्र पर निर्भर नहीं करता है, लेकिन कार्यान्वित QueryInterface पर, जिसके कार्यान्वयन को किसी तरह इस पदानुक्रम की आवश्यकता है इधर उधर हो जाना। यह वह जगह है जहां कुछ अशुद्धता काम में आती है: बॉस :: इनहेरिट, जिसमें निम्नलिखित कार्यान्वयन हैं:

 namespace Boss { template <typename ... T> struct Inherit : public T ... { virtual ~Inherit() {} typedef std::tuple<T ... > BaseInterfaces; BOSS_DECLARE_IBASE_METHODS() }; }

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

उपयोगकर्ता इंटरफेस को कैसे और क्यों परिभाषित किया जाए, इस पर विचार किया गया है, लेकिन उन्हें कहीं और किसी तरह लागू करने की आवश्यकता है। सबसे पहले, इंटरफेस के कार्यान्वयन का एक छोटा सा उदाहरण:

 struct IFace1 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace1") virtual void Mtd1() = 0; }; class Face_1 : public Boss::CoClass<Boss::Crc32("Face_1"), IFace1> { public: virtual void Mtd1() { // TODO: } };

और एक बेहतरीन उदाहरण

 struct IFace1 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace1") virtual void Mtd1() = 0; }; struct IFace2 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace2") virtual void Mtd2() = 0; }; struct IFace3 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace3") virtual void Mtd3() = 0; }; class Face1 : public Boss::CoClass<Boss::Crc32("Face1"), IFace1> { public: virtual void Mtd1() { // TODO: } }; class Face2 : public Boss::CoClass<Boss::Crc32("Face2"), IFace2> { public: virtual void Mtd2() { // TODO: } }; class Face123 : public Boss::CoClass<Boss::Crc32("Face123"), Face1, Face2, IFace3> { public: virtual void Mtd3() { // TODO: } }; struct IFace4 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace4") virtual void Mtd4() = 0; }; struct IFace5 : Boss::Inherit<Boss::IBase> { BOSS_DECLARE_IFACEID("IFace5") virtual void Mtd5() = 0; }; struct IFace6 : Boss::Inherit<IFace4, IFace5> { BOSS_DECLARE_IFACEID("IFace6") virtual void Mtd6() = 0; }; class Face123456 : public Boss::CoClass<Boss::Crc32("Face123456"), Face123, IFace6> { public: virtual void Mtd4() { // TODO: } virtual void Mtd5() { // TODO: } virtual void Mtd6() { // TODO: } };

कार्यान्वयन के लिए सभी "खलनायकों" के साथ, जिसे उसे बाहर करना होगा। यह स्पष्ट है कि आप अधिक अराजकता कर सकते हैं। दिया गया उदाहरण "क्यूब्स" के निर्माण में कार्यान्वयन की संभावनाओं का वर्णन करता है।

यह ध्यान रखना मुश्किल नहीं है कि प्रत्येक कार्यान्वयन CoClass से विरासत में मिला है। CoClass का एक बहुत ही सरल कार्यान्वयन है:

 namespace Boss { template <ClassId ClsId, typename ... T> class CoClass : public virtual Private::CoClassAdditive , public T ... { public: typedef std::tuple<T ... > BaseEntities; CoClass() : Constructed(false) { } // IBase BOSS_DECLARE_IBASE_METHODS() private: template <typename Y> friend void Private::SetConstructedFlag(Y *, bool); template <typename Y> friend bool Private::GetConstructedFlag(Y *); bool Constructed; }; }

इनहेरिट संरचना की तरह यह वर्ग, हस्तांतरित संस्थाओं की सूची से विरासत में मिला है, इस वंशानुक्रम सूची को "बूँदें", कुछ से विरासत में मिला

अशुद्धियाँ (निजी :: CoClassAdditive) / ब्रांड

 namespace Boss { namespace Private { struct CoClassAdditive { virtual ~CoClassAdditive() {} }; } }

(जिसका उपयोग संस्थाओं को वर्गीकृत करने के लिए किया जाएगा: इंटरफ़ेस या कार्यान्वयन), कंपाइलर भी गैरकानूनीता को समाप्त करता है (BOSS_DECLARE_IBASE_METHODS के माध्यम से तरीकों को धक्का देकर) और निर्माण की जा रही वस्तु का एक चिन्ह होता है (बाधित)।

वहाँ इंटरफेस हैं, कार्यान्वयन हैं, लेकिन अभी तक IBase का कार्यान्वयन नहीं हुआ है। इस इंटरफ़ेस का कार्यान्वयन संभवतः सबसे कठिन में से एक होगा।

उपरोक्त बड़े उदाहरण से एक वस्तु बनाने के लिए कुछ इस तरह दिखेगा:

 auto Obj = Boss::Base<Face123456>::Create();

बॉस :: बेस बॉस का एक कार्यान्वयन वर्ग है :: IBase। कार्यान्वयन में, कुछ संचालन करने के लिए वर्ग पदानुक्रम को बायपास करना आवश्यक है। तो ऊपर के उदाहरण के लिए, एक सरलीकृत पदानुक्रम इस तरह दिखेगा:

सही की तलाश में कक्षा पदानुक्रम को दरकिनार कर मैं थोड़ी देर के लिए स्थगित कर दूंगा। जल्दी से सरल तरीकों से चलें।

AddRef (रेफरेंस काउंट बढ़ाता है) और रिलीज़ को रिफ़र करने से रेफरेंस काउंटिंग की जाती है और रेफरेंस काउंट कम हो जाता है और जब जीरो पहुँच जाता है तो ऑब्जेक्ट डिलीट कर देता है, इसे डिलीट कर रहा है)। चूंकि यह माना जाता है कि वस्तुओं का उपयोग बहु-थ्रेडेड वातावरण में किया जा सकता है, काउंटर के साथ काम std :: atomic के माध्यम से किया जाता है, जो बहु-थ्रेडेड वातावरण में परमाणु को बढ़ाने और कम करने की अनुमति देता है। हां, अंत में सी ++ ने थ्रेड्स के अस्तित्व को मान्यता दी और थ्रेड्स और सिंक्रोनाइज़ेशन प्राइमेटिव्स के साथ काम करने के लिए समर्थन था।

बनाएँ विधि में यह कार्यान्वयन है:

 template <typename ... Args> static RefObjPtr<T> Create(Args const & ... args) { Private::ModuleCounter::ScopedLock Lock; RefObjPtr<T> NewInst(new Base<T>(args ...)); Private::FinalizeConstruct<T>::Construct(NewInst.Get()); return std::move(NewInst); }

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

ModuleCounter

 namespace Boss { namespace Private { struct ModuleRefCounterTypeStub { }; template <typename T> class ModuleRefCounter { public: static void AddRef() { Counter.fetch_add(1, std::memory_order_relaxed); } static void Release() { Counter.fetch_sub(1, std::memory_order_relaxed); } static UInt GetCounter() { return Counter; } private: static std::atomic<UInt> Counter; public: class ScopedLock { public: ScopedLock(ScopedLock const &) = delete; ScopedLock(ScopedLock &&) = delete; ScopedLock operator = (ScopedLock const &) = delete; ScopedLock operator = (ScopedLock &&) = delete; ScopedLock() { ModuleRefCounter<T>::AddRef(); } ~ScopedLock() { ModuleRefCounter<T>::Release(); } }; }; template <typename T> std::atomic<UInt> ModuleRefCounter<T>::Counter(0); typedef ModuleRefCounter<ModuleRefCounterTypeStub> ModuleCounter; } }

मॉड्यूल संदर्भ गणना को नियंत्रित करता है। दो संदर्भ काउंटर हैं - यह सीधे ऑब्जेक्ट पर संदर्भ काउंटर है और सभी मॉड्यूल लिंक का काउंटर है। मॉड्यूल के संदर्भ काउंटर को समझने में सक्षम होने के लिए आवश्यक है जब मॉड्यूल में "जीवित" ऑब्जेक्ट होते हैं, और जब एक नहीं होता है और मॉड्यूल को अनलोड किया जा सकता है।

स्थैतिक पुस्तकालयों को त्यागने के लिए और मॉड्यूल मॉड्यूल में से प्रत्येक के लिए "लोनर" पैटर्न (प्रत्येक मॉड्यूल के लिए) को लागू करने के लिए, आपको इसे केवल सम्मिलित फ़ाइल में लागू करने की आवश्यकता है, फिर टेम्पलेट और स्थिर वस्तुओं के साथ एक चाल काफी उपयोगी है। आप पिछले लेख में इसके बारे में अधिक पढ़ सकते हैं। इसे संक्षेप में निम्नानुसार वर्णित किया जा सकता है: यदि आप एक स्थिर क्षेत्र के साथ एक प्रकार का टेम्पलेट बनाते हैं और इसे किसी भी प्रकार से त्वरित करते हैं, तो इस ऑब्जेक्ट का एक उदाहरण पूरे मॉड्यूल में केवल एक ही होगा। यह एक छोटी सी चाल का उपयोग करता है जिसमें एक cpp-file में कहीं भी कार्यान्वित किए बिना सम्मिलित फ़ाइलों में कुंवारा लिखने के लिए उपयोग किया जाता है।
और इस सुंदर समाधान में एक रेक है, एक बच्चों की रेक: संभाल दो गुना छोटी है, यह अधिक सटीक और दर्दनाक तरीके से धड़कता है ... यह समाधान डीडी में ठीक काम करता है, लेकिन। In में मैंने एक समस्या पकड़ी है: एक ही प्रकार से तुरंत स्थिर क्षेत्रों के साथ एक टेम्पलेट एक बन गया। प्रक्रिया के भाग के रूप में इस मॉडल के घटकों के साथ .so के लिए! मुझे बाद में क्यों एहसास हुआ, लेकिन मुझे गुमनाम नामों और एक सम्मिलित फ़ाइल के आधार पर एक सरल के पक्ष में सुंदर निर्णय को छोड़ना पड़ा, जो प्रत्येक मॉड्यूल में एक से अधिक बार शामिल नहीं है (जो परवाह करता है - बॉस / शामिल / प्लगइन / मॉड्यूल। एच)।

C ++ को कई लोगों द्वारा एक ऐसी भाषा माना जाता है जो "पैर में खुद को गोली मारना" आसान बनाता है। और, एक नियम के रूप में, यह अक्सर उसके खिलाफ सताया जाता है कि संसाधनों के आवंटन / रिलीज से संबंधित संचालन की जोड़ी के कारण, और विशेष रूप से स्मृति में। लेकिन अगर आप स्मार्ट पॉइंटर्स का इस्तेमाल करते हैं, तो एक सिरदर्द कम हो जाता है। RefObjPtr केवल एक स्मार्ट पॉइंटर है जो ऑब्जेक्ट के जीवनकाल को नियंत्रित करने के लिए AddRef और Release को कॉल करता है और प्रोग्राम में जब इसका उपयोग किया जाता है, तो AddRef और रिलीज़ तरीके उपयोगकर्ता कोड में नहीं होने चाहिए।

नए मानक का एक ऐसा हिस्सा जो r- मान के रूप में आपको अधिक इष्टतम संस्थाओं को लिखने की अनुमति देता है; उदाहरण के लिए, सभी एक ही RefObjPtr कॉपी कंस्ट्रक्टर्स पर एक बार फिर AddRef / रिलीज़ को कॉल किए बिना किसी ऑब्जेक्ट को वापस करने के लिए (रिटर्न std :: move (NewInst))।

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

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

 template <typename T> class HasFinalizeConstruct { private: typedef char (&No)[1]; typedef char (&Yes)[10]; template <typename U, void (U::*)() = &U::FinalizeConstruct> struct CheckMtd { typedef Yes Type; }; template <typename U> static typename CheckMtd<U>::Type Check(U const *); static No Check(...); public: enum { Has = sizeof(Check(static_cast<T const *>(0))) == sizeof(Yes) }; };

अंतिम रूप से कॉल करने के लिए सभी तर्क

 namespace Boss { namespace Private { template <bool HasFinalizeConstruct> struct CallFinalizeConstruct { template <typename ObjType> static void Call(ObjType *obj) { obj->FinalizeConstruct(); SetConstructedFlag(obj, true); } }; template <> struct CallFinalizeConstruct<false> { template <typename ObjType> static void Call(ObjType *obj) { SetConstructedFlag(obj, true); } }; template < typename T, bool IsCoClass = std::is_base_of<CoClassAdditive, T>::value > struct FinalizeConstruct { template <typename ObjType> static void Construct(ObjType *) { } }; template <typename T, std::size_t I> struct FinalizeConstructIter { template <typename ObjType> static void Construct(ObjType *obj) { typedef typename std::tuple_element<I, T>::type CurType; FinalizeConstructIter<T, I - 1>::Construct(obj); FinalizeConstruct<CurType>::Construct(static_cast<CurType *>(obj)); } }; template <typename T> struct FinalizeConstructIter<T, -1> { template <typename ObjType> static void Construct(ObjType *) { } }; template <typename T> struct FinalizeConstruct<T, true> { template <typename ObjType> static void Construct(ObjType *obj) { typedef typename T::BaseEntities BaseEntities; enum { BaseEntityCount = std::tuple_size<BaseEntities>::value - 1 }; FinalizeConstructIter<BaseEntities, BaseEntityCount>::Construct(obj); CallFinalizeConstruct<HasFinalizeConstruct<T>::Has>::Call(obj); } }; } }

यह टेम्पलेट्स के निजी विशेषज्ञता पर बनाया गया है और आधार वर्गों के प्रकार के साथ "खोदा" ट्यूपल्स के माध्यम से पदानुक्रम के माध्यम से चलना है। मानक पुस्तकालय में प्रकारों के साथ काम करने के लिए उपकरण होने लगे, इसलिए यह निर्धारित करने के लिए कि क्या कोई वर्ग कार्यान्वयन वर्ग से संबंधित है, अब आप अपने स्वयं के कार्यान्वयन को लिखने के बजाय std :: is_base_of का उपयोग कर सकते हैं। आप अलेक्जेंड्रेस्कु शैली में टाइप सूचियों के बजाय std :: tuple का उपयोग कर सकते हैं।

डिजाइनरों के लिए सादृश्य तैयार है, लेकिन विनाशकारी के लिए सादृश्य के बारे में क्या? उसके बिना कहाँ। मॉडल विध्वंसकों को कॉल करने के क्रम में वर्ग पदानुक्रम को पार करने के लिए तर्क को लागू करता है, कार्यान्वयन कक्षा में पहले की तरह एक ही SFINAE विधि के माध्यम से खोज करता है और यदि कोई कॉल है। प्रायरलीजेस के साथ काम करने के लिए तर्क का कार्यान्वयन फ़ाइनलीकेकस्ट्रक्चर के तर्क के समान है, लेकिन केवल रिवर्स ऑर्डर में।

अब वस्तु के पूरी तरह से तैयार होने और वस्तु के विनाश से पहले कुछ जारी करने के बाद वस्तु को फिर से डिज़ाइन करने का अवसर है। लेकिन कंस्ट्रक्टर में, आप एक अपवाद को फेंककर समस्या की रिपोर्ट कर सकते हैं। इस मॉडल में एक ही व्यवहार लागू किया गया है: पदानुक्रम में किसी भी फ़ाइनलीजकॉन्स्ट्रक्ट विधि में, एक अपवाद को फेंक दिया जा सकता है और फ़ाइनलिज़कॉन्स्ट्रक्ट श्रृंखला के बाकी हिस्सों को अब नहीं बुलाया जाएगा, इसके अलावा, पदानुक्रम की उन वस्तुओं के लिए जिनके लिए फ़ाइनलीकोन्स्ट्रक्ट पहले ही गुजर चुका है, पहले से हीRelease को सफलतापूर्वक कहा जाएगा। यह C ++ कंस्ट्रक्टर्स और डिस्ट्रक्टर्स के लिए एक पूर्ण सादृश्य देता है। इससे पहले कि रिलीज़ विधि को लागू करने से पहलेRelease को बुलाया जाए, और जब PreRelease पदानुक्रम को ट्रेस किया जाए, तो इसे केवल उन ऑब्जेक्ट्स के लिए कहा जाएगा, जिसके लिए एक सफल फ़ाइनलकॉन्स्ट्रक्ट कॉल पास हुई है, और कॉल की सफलता CoClass (याद रखें?) में स्थित ध्वज द्वारा निर्धारित की गई है। यह भी ध्यान देने योग्य है कि अगर कक्षा में इन तरीकों की जोड़ी की आवश्यकता नहीं है, तो केवल एक ही मौजूद हो सकता है, यदि बिल्कुल भी।

यह तर्क को लागू करने के लिए बनी हुई है

QueryInterface

 namespace Boss { namespace Private { template <typename T, bool IsImpl> struct QueryInterface; template <typename T, std::size_t I> struct QueryInterfacesListIter { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { typedef typename std::tuple_element<I, T>::type CurType; if (ifaceId == InterfaceTraits<CurType>::Id) { *iface = static_cast<CurType *>(obj); return Status::Ok; } return QueryInterfacesListIter<T, I - 1>::Query(obj, ifaceId, iface) == Status::Ok ? Status::Ok : QueryInterface<CurType, false>::Query(obj, ifaceId, iface); } }; template <typename T> struct QueryInterfacesListIter<T, -1> { template <typename ObjType> static RetCode Query(ObjType *, InterfaceId, Ptr *) { return Status::InterfaceNotFound; } }; template <typename T> struct QueryFromInterfacesList { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { typedef typename T::BaseInterfaces BaseInterfaces; enum { BaseInterfaceCount = std::tuple_size<BaseInterfaces>::value - 1 }; return QueryInterfacesListIter<BaseInterfaces, BaseInterfaceCount>::Query(obj, ifaceId, iface); } }; template <> struct QueryFromInterfacesList<IBase> { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { if (ifaceId == InterfaceTraits<IBase>::Id) { *iface = static_cast<IBase *>(obj); return Status::Ok; } return Status::InterfaceNotFound; } }; template < typename T, bool IsCoClass = std::is_base_of<CoClassAdditive, T>::value > struct QueryInterface { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { if (ifaceId == InterfaceTraits<T>::Id) { *iface = static_cast<T *>(obj); return Status::Ok; } return QueryFromInterfacesList<T>::Query(static_cast<T *>(obj), ifaceId, iface); } }; template <typename T, std::size_t I> struct QueryInterfaceIter { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { typedef typename std::tuple_element<I, T>::type CurType; return QueryInterface<CurType>::Query(static_cast<ObjType *>(obj), ifaceId, iface) == Status::Ok ? Status::Ok : QueryInterfaceIter<T, I - 1>::Query(obj, ifaceId, iface); } }; template <typename T> struct QueryInterfaceIter<T, -1> { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { return Status::InterfaceNotFound; } }; template <typename T> struct QueryInterface<T, true> { template <typename ObjType> static RetCode Query(ObjType *obj, InterfaceId ifaceId, Ptr *iface) { typedef typename T::BaseEntities BaseEntities; enum { BaseEntityCount = std::tuple_size<BaseEntities>::value - 1 }; return QueryInterfaceIter<BaseEntities, BaseEntityCount>::Query(static_cast<T *>(obj), ifaceId, iface); } }; } }

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

बॉस कार्यान्वयन :: IBase

 namespace Boss { template <typename T> class Base final : public T { public: Base(Base const &) = delete; Base const & operator = (Base const &) = delete; Base(Base &&) = delete; Base const & operator = (Base &&) = delete; template <typename ... Args> static RefObjPtr<T> Create(Args const & ... args) { Private::ModuleCounter::ScopedLock Lock; RefObjPtr<T> NewInst(new Base<T>(args ...)); Private::FinalizeConstruct<T>::Construct(NewInst.Get()); return std::move(NewInst); } private: std::atomic<UInt> Counter; template <typename ... Args> Base(Args const & ... args) : T(args ...) , Counter(0) { Private::ModuleCounter::AddRef(); } virtual ~Base() { Private::ModuleCounter::Release(); } // IBase virtual UInt BOSS_CALL AddRef() { return Counter.fetch_add(1, std::memory_order_relaxed) + 1; } virtual UInt BOSS_CALL Release() { UInt CurValue = Counter.fetch_sub(1, std::memory_order_relaxed); if (CurValue == 1) { Private::BeforeRelease<T>::Release(static_cast<T *>(this)); std::atomic_thread_fence(std::memory_order_acquire); delete this; } return CurValue - 1; } virtual RetCode BOSS_CALL QueryInterface(InterfaceId ifaceId, Ptr *iface) { RetCode Ret = Private::QueryInterface<T>::Query(static_cast<T *>(this), ifaceId, iface); if (Ret == Status::Ok) AddRef(); return Ret; } }; }

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

कोर तैयार है! सभी सबसे जटिल और दिलचस्प वर्णन किया गया है। आगे सब कुछ बहुत सरल और अधिक भी होगा, बिना पहेली के।

प्लग-इन

इस भाग में, हम प्लगइन्स के संगठन पर ध्यान केंद्रित करेंगे। वर्तमान संदर्भ में, प्लग-इन को डायनेमिक लाइब्रेरी (.so / .dll) के रूप में समझा जाना चाहिए, जो इंटरफेस (घटकों) के कार्यान्वयन कक्षाओं को होस्ट करता है और इन कार्यान्वयन कक्षाओं की वस्तुओं तक पहुंचने के लिए कार्यों का एक छोटा समूह है।

लेख का यह हिस्सा, मेरी राय में, सबसे सरल है, क्योंकि "टेम्पलेट पर प्रोग्रामिंग" और संकलक के अन्य नकलीपन नहीं है। बस प्लग-इन सिस्टम के आयोजन के लिए इंटरफेस और कार्यान्वयन का एक सेट बनाना।

उनके घरों में घटक के "जीवन" के लिए, एक राज्य के ढांचे के भीतर (प्लग-इन), प्रक्रिया कहा जाता है, इसलिए इसका उपयोग नहीं किया जाता है:

प्लगइन्स / घटकों / सेवाओं की रजिस्ट्री
वर्ग का कारखाना
लोडर

सेवा रजिस्ट्री - सेवा के बारे में सभी जानकारी संग्रहीत करने के लिए एक जगह:

सेवा आईडी
-
(so / dll) ,
Proxy/Stub' .

इस जानकारी के आधार पर, क्लास फैक्ट्री आवश्यक प्लग-इन को लोड करने और इंटरफ़ेस कार्यान्वयन ऑब्जेक्ट बनाने में सक्षम होगी।

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

सेवा रजिस्ट्री सिर्फ एक विधि के साथ एक इंटरफ़ेस की आपूर्ति करती है, जो वर्ग कारखाने के लिए आवश्यक जानकारी प्राप्त करने के लिए पर्याप्त है।

 namespace Boss { struct IServiceRegistry : public Inherit<IBase> { BOSS_DECLARE_IFACEID("Boss.IServiceRegistry") virtual RetCode BOSS_CALL GetServiceInfo(ClassId clsId, IServiceInfo **info) const = 0; }; }

लेकिन सेवा रजिस्ट्री कार्यान्वयन वर्ग खुद कई इंटरफेस की आपूर्ति कर सकता है। यह सब क्या था? टाइपसेट घटक बनाएं।

सेवा रजिस्ट्री कार्यान्वयन वर्ग

 namespace Boss { class ServiceRegistry : public CoClass < Service::Id::ServiceRegistry, IServiceRegistry, IServiceRegistryCtrl, ISerializable > { public: ServiceRegistry(); virtual ~ServiceRegistry(); private: // IServiceRegistry virtual RetCode BOSS_CALL GetServiceInfo(ClassId clsId, IServiceInfo **info) const; // IServiceRegistryCtrl virtual RetCode BOSS_CALL AddService(IServiceInfo *service); virtual RetCode BOSS_CALL DelService(ServiceId serviceId); // ISerializable virtual RetCode BOSS_CALL Load(IIStream *stream); virtual RetCode BOSS_CALL Save(IOStream *stream); // ... }; }

यानी कार्यान्वयन रजिस्ट्री (IServiceRegistryCtrl) में हेरफेर करने और इसे लोड करने और इसे सहेजने (ISerializable) के लिए एक इंटरफ़ेस प्रदान करता है।

कक्षा कारखाना कार्यान्वयन

 namespace Boss { class ClassFactory : public CoClass < Service::Id::ClassFactory, IClassFactory, IClassFactoryCtrl > { public: // IClassFactory virtual RetCode BOSS_CALL CreateObject(ClassId clsId, IBase **inst); // IClassFactoryCtrl virtual RetCode BOSS_CALL SetRegistry(IServiceRegistry *registry); // ... }; }

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

बूटलोडर कोड काफी सरल है, लेकिन, दुर्भाग्यवश, C ++ 11 ने प्लेटफॉर्म (OS) को थोड़ा पहचाना। उन्होंने मल्टीथ्रेडिंग को मान्यता दी, लेकिन अभी तक गतिशील पुस्तकालयों जैसी कोई चीज नहीं है। इसलिए लोडिंग मॉड्यूल के लिए ऑपरेटिंग सिस्टम के आधार पर कोड का उपयोग किया जाएगा। जरूर गहरा छिपा है। PImple को वापस बुलाना अच्छा होगा , लेकिन चूँकि यह कोर्स स्टैटिक लाइब्रेरियों को छोड़ने के लिए लिया गया है, इसलिए यह थोड़ा अलग होगा: प्रत्येक हेडर के लिए इसका शीर्षक फ़ाइल में लागू होता है और फ़ाइल इंटरफ़ेस जो विश्लेषण करता है कि __linux__ और _WIN32 मैक्रोज़ के आधार पर क्या शामिल किया जाए।

एक प्रक्रिया में रहने वाले प्लगइन मॉडल के ढांचे के भीतर सेवाओं के उपयोग का एक छोटा सा उदाहरण:

 #include <iostream> #include "plugin/loader.h" #include "plugin/module.h" int main() { try { Boss::Loader Ldr("Registry.xml", "./libservice_registry.so", "./libclass_factory.so"); Boss::RefObjQIPtr<Boss::IBase> Inst; Inst = Ldr.CreateObject<Boss::IBase>(Boss::Crc32("MyClass")); } catch (std::exception const &e) { std::cerr << e.what() << std::endl; } return 0; }

जैसा कि अनुभाग की शुरुआत में उल्लेख किया गया है, सब कुछ काफी सरल है, यह केवल सहायक कोड लिखने के लिए थोड़ा सा लिया।

उदाहरण

सबसे अच्छा उदाहरण एक वास्तविक कार्य है, न कि एक कृत्रिम रूप से आविष्कार किए गए पाइलिंग जो अधिकतम या इस अवसर को प्रदर्शित करता है।

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

एक बार फिर मैं सेवाओं की रजिस्ट्री के लिए एक वर्ग कार्यान्वयन दूंगा।

सेवा रजिस्ट्री कार्यान्वयन

 namespace Boss { class ServiceRegistry : public CoClass < Service::Id::ServiceRegistry, IServiceRegistry, IServiceRegistryCtrl, ISerializable > { public: ServiceRegistry(); virtual ~ServiceRegistry(); private: // IServiceRegistry virtual RetCode BOSS_CALL GetServiceInfo(ClassId clsId, IServiceInfo **info) const; // IServiceRegistryCtrl virtual RetCode BOSS_CALL AddService(IServiceInfo *service); virtual RetCode BOSS_CALL DelService(ServiceId serviceId); // ISerializable virtual RetCode BOSS_CALL Load(IIStream *stream); virtual RetCode BOSS_CALL Save(IOStream *stream); // ... }; }

अब यहाँ क्या हो रहा है इसका वर्णन करने का प्रयास करें ...
एक या अधिक इंटरफेस के लिए एक कार्यान्वयन वर्ग बनाने के लिए, आपको CoClass टेम्प्लेट वर्ग से व्युत्पन्न वर्ग बनाने की आवश्यकता है। यह वर्ग कार्यान्वयन वर्ग के पहचानकर्ता को स्वीकार करता है (जो कि क्लास फैक्ट्री के माध्यम से वस्तु बनाते समय पहले से ही इस्तेमाल किया जा सकता है) और पैरामीटर के रूप में इंटरफेस के वंशानुगत इंटरफेस या तैयार-किए गए कार्यान्वयन की एक सूची। यदि आप सेवा रजिस्ट्री के दिए गए कार्यान्वयन वर्ग को देखते हैं, तो आप इसमें पहचानकर्ता देख सकते हैं (सेवा :: Id :: ServiceRegistry) और निम्नलिखित इंटरफेस हैं जो इस वर्ग में कार्यान्वित किए जाते हैं (IServiceRegistry - उस सेवा का इंटरफ़ेस जो क्लास फैक्ट्री द्वारा उपयोग किया जाएगा; ISrviceRegistryCtrl - रजिस्ट्री प्रबंधन इंटरफ़ेस; ISerializable - रजिस्ट्री को कहीं से सहेजा जाना चाहिए और कहीं से लोड किया जाना चाहिए, और यह इंटरफ़ेस आपको वह प्रदर्शन करने की अनुमति देता है जो आवश्यक है)।इस पर, कंपोनेंट बनाने का सारा काम पूरा हो गया है और आपको सिर्फ इसके तरीकों को लागू करने की जरूरत है।

घटक तैयार है। यह किसी भी तरह इसे प्रकाशित करने के लिए बनी हुई है, अर्थात उस मॉड्यूल के बाहर से इसे एक्सेस देना जिसमें यह स्थित है।

ऐसा करने के लिए, मैक्रो BOSS_DECLARE_MODULE_ENTRY_POINT का उपयोग करें

 #include "service_registry.h" #include "plugin/module.h" namespace { typedef std::tuple < Boss::ServiceRegistry > ExportedCoClasses; } BOSS_DECLARE_MODULE_ENTRY_POINT("ServiceRegistry", ExportedCoClasses)

एक स्ट्रिंग को मैक्रो को पास किया जाता है जिसमें से CRC32 की गणना की जाएगी, जिसका उपयोग मॉड्यूल की पहचानकर्ता और वर्ग मॉड्यूल की सूची के रूप में किया जाता है जो इस मॉड्यूल द्वारा निर्यात किए जाते हैं। जिसके बाद घटक और उसके मॉड्यूल तैयार हैं (और मॉड्यूल में कई घटक हो सकते हैं), इसका उपयोग रजिस्ट्री में पंजीकरण करके किया जा सकता है (अपवाद: मॉडल के सामान्य उपयोग के लिए सेवाओं की रजिस्ट्री और वर्ग का कारखाना पंजीकृत नहीं किया जा सकता है)।

एक अन्य समान उदाहरण: एक वर्ग कारखाने का कार्यान्वयन, जो ऊपर भी दिया गया है।

वर्ग का कारखाना

 namespace Boss { class ClassFactory : public CoClass < Service::Id::ClassFactory, IClassFactory, IClassFactoryCtrl > { public: // IClassFactory virtual RetCode BOSS_CALL CreateObject(ClassId clsId, IBase **inst); // IClassFactoryCtrl virtual RetCode BOSS_CALL SetRegistry(IServiceRegistry *registry); // ... }; }

पूरी तरह से एक जैसा उदाहरण। इसके अलावा CoClass से विरासत, पहचानकर्ता और कार्यान्वित इंटरफेस की एक सूची। वर्ग कारखाना एक अलग मॉड्यूल में स्थित है, क्रमशः, इसका अपना है

प्रवेश बिंदु

 #include "class_factory.h" #include "plugin/module.h" namespace { typedef std::tuple < Boss::ClassFactory > ExportedCoClasses; } BOSS_DECLARE_MODULE_ENTRY_POINT("ClassFactory", ExportedCoClasses)

सेवाओं की रजिस्ट्री के लिए एक ही प्रवेश बिंदु।

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

सेवा की जानकारी लागू करना

 #ifndef __BOSS_PLUGIN_SERVICE_INFO_H__ #define __BOSS_PLUGIN_SERVICE_INFO_H__ #include "../core/base.h" #include "../core/error_codes.h" #include "../core/ref_obj_ptr.h" #include "../common/enum.h" #include "../common/entity_id.h" #include "../common/string.h" #include "iservice_info.h" #include <string> namespace Boss { namespace Private { template <typename T, bool = !!std::is_base_of<IServiceInfo, T>::value> class ServiceInfo; template <typename T> class ServiceInfo<T, true> : public CoClass<Crc32("Boss.ServiceInfo"), T> { public: // … void SetServiceId(ServiceId srvId) { // ... } void AddCoClassId(ClassId clsId) { // ... } void AddCoClassIds(RefObjPtr<IEnum> coClassIds) { // ... } private: // … // IServiceInfo virtual RetCode BOSS_CALL GetServiceId(ServiceId *serviceId) const { // ... } virtual RetCode BOSS_CALL GetClassIds(IEnum **ids) const { // ... } }; } class LocalServiceInfo : public CoClass<Crc32("Boss.LocalServiceInfo"), Private::ServiceInfo<ILocalServiceInfo>> { public: void SetModulePath(std::string const &path) { // ... } void SetModulePath(RefObjPtr<IString> path) { // ... } private: // ... // ILocalServiceInfo virtual RetCode BOSS_CALL GetModulePath(IString **path) const { // ... } }; class RemoteServiceInfo : public CoClass<Crc32("Boss.RemoteServiceInfo"), Private::ServiceInfo<IRemoteServiceInfo>> { public: void SetProps(RefObjPtr<IPropertyBag> props) { // ... } private: // ... // IRemoteServiceInfo virtual RetCode BOSS_CALL GetProperties(IPropertyBag **props) const { // ... } }; } #endif // !__BOSS_PLUGIN_SERVICE_INFO_H__

ServiceInfo को लागू करना थोड़ा जटिल लग सकता है। यहाँ एक टेम्पलेट क्यों है? यह मेरे लिए हुई डेटा संरचना के कार्यान्वयन की सूक्ष्मता है, और घटक मॉडल / प्लग-इन सिस्टम के लिए श्रद्धांजलि नहीं है। इस कार्यान्वयन के कारण को थोड़ा स्पष्ट करने के लिए, मैं इंटरफ़ेस दूंगा:

सेवा सूचना इंटरफ़ेस

 #ifndef __BOSS_PLUGIN_ISERVICE_INFO_H__ #define __BOSS_PLUGIN_ISERVICE_INFO_H__ #include "../core/ibase.h" #include "../common/ienum.h" #include "../common/istring.h" #include "../common/iproperty_bag.h" namespace Boss { struct IServiceInfo : public Inherit<IBase> { BOSS_DECLARE_IFACEID("Boss.IServiceInfo") virtual RetCode BOSS_CALL GetServiceId(ServiceId *serviceId) const = 0; virtual RetCode BOSS_CALL GetClassIds(IEnum **ids) const = 0; }; struct ILocalServiceInfo : public Inherit<IServiceInfo> { BOSS_DECLARE_IFACEID("Boss.ILocalServiceInfo") virtual RetCode BOSS_CALL GetModulePath(IString **path) const = 0; }; struct IRemoteServiceInfo : public Inherit<IServiceInfo> { BOSS_DECLARE_IFACEID("Boss.IRemoteServiceInfo") virtual RetCode BOSS_CALL GetProperties(IPropertyBag **props) const = 0; }; } #endif // !__BOSS_PLUGIN_ISERVICE_INFO_H__

इंटरफेस और कार्यान्वयन की विरासत के साथ थोड़ा और अधिक समझने योग्य कार्यान्वयन कर्नेल विवरण में फैंसी Face123456 वर्ग के साथ बिना किसी टेम्पलेट के दिया गया है :)

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

लोडर

 #ifndef __BOSS_PLUGIN_LOADER_H__ #define __BOSS_PLUGIN_LOADER_H__ #include "iservice_registry.h" #include "iclass_factory.h" #include "iclass_factory_ctrl.h" #include "module_holder.h" #include "service_ids.h" #include "core/exceptions.h" #include "common/file_stream.h" #include "common/iserializable.h" #include <string> namespace Boss { BOSS_DECLARE_RUNTIME_EXCEPTION(Loader) class Loader final { public: Loader(Loader const &) = delete; Loader& operator = (Loader const &) = delete; Loader(std::string const &registryFilePath, std::string const &srvRegModulePath, std::string const &clsFactoryModulePath) : SrvRegistry([&] () { auto SrvRegModule(ModuleHolder(std::move(DllHolder(srvRegModulePath)))); auto SrvReg = SrvRegModule.CreateObject<IServiceRegistry>(Service::Id::ServiceRegistry); RefObjQIPtr<ISerializable> Serializable(SrvReg); if (!Serializable.Get()) throw LoaderException("Failed to get ISerializable interface from Registry object."); if (Serializable->Load(Base<IFileStream>::Create(registryFilePath).Get()) != Status::Ok) throw LoaderException("Failed to load Registry."); return std::move(std::make_pair(std::move(SrvRegModule), std::move(SrvReg))); } ()) , ClsFactory([&] () { auto ClassFactoryModule(ModuleHolder(std::move(DllHolder(clsFactoryModulePath)))); auto NewClsFactory = ClassFactoryModule.CreateObject<IClassFactory>(Service::Id::ClassFactory); RefObjQIPtr<IClassFactoryCtrl> Ctrl(NewClsFactory); if (!Ctrl.Get()) throw LoaderException("Failed to get ICalssFactoryCtrl interface from ClassFactory object."); if (Ctrl->SetRegistry(SrvRegistry.second.Get()) != Status::Ok) throw LoaderException("Failed to set Registry into ClassFactory."); return std::move(std::make_pair(std::move(ClassFactoryModule), std::move(NewClsFactory))); } ()) { } template <typename T> RefObjPtr<T> CreateObject(ClassId clsId) { RefObjPtr<IBase> NewInst; if (ClsFactory.second->CreateObject(clsId, NewInst.GetPPtr()) != Status::Ok) throw LoaderException("Failed to create object."); RefObjQIPtr<T> Ret(NewInst); if (!Ret.Get()) throw LoaderException("Interface not found."); return Ret; } ~Loader() { ClsFactory.second.Release(); SrvRegistry.second.Release(); } private: std::pair<ModuleHolder, RefObjPtr<IServiceRegistry>> SrvRegistry; std::pair<ModuleHolder, RefObjPtr<IClassFactory>> ClsFactory; }; } #endif // !__BOSS_PLUGIN_LOADER_H__

उपरोक्त उदाहरणों के अलावा, C ++ 03 में पिछले संस्करण के कार्यान्वयन के साथ लेख के उदाहरण प्रासंगिक हैं। एकमात्र अंतर पहचानकर्ताओं के साथ काम करना है। नए मॉडल में, आपको कार्यान्वयन वर्ग में एक अलग मैक्रो जोड़ने की आवश्यकता नहीं है, जिसके बारे में आप भूल सकते हैं। यदि आप नए मॉडल में पहचानकर्ता के बारे में भूल जाते हैं, तो संकलक आपको इसकी याद दिलाएगा, क्योंकि अब यह एक टेम्पलेट पैरामीटर है।

निष्कर्ष

कुछ बड़ा विचार था, लेकिन यह केवल 2/3 पर ही साकार हो गया:

पूरी तरह से लागू किया गया कोर
प्लग-इन सिस्टम के अस्तित्व के लिए बुनियादी सेवाओं को लागू किया
अन्य प्रक्रियाओं में रहने वाले प्लगइन्स को ध्यान में नहीं लाया जाता है, और सभी रूढ़ियों को काट दिया जाता है ताकि कोड को रोकना न पड़े

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

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

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

सोर्स कोड जीथब पर उपलब्ध है । इसमें न्यूनतम बिल्ड स्क्रिप्ट है। यह आपकी परियोजनाओं के लिए उदाहरण और विचारों के स्रोत के रूप में काम कर सकता है।

ध्यान देने के लिए आप सभी का धन्यवाद!

C ++ 11 में एक अभ्यास के रूप में प्लगइन प्रणाली