🔱 🍢 👩‍🎓 बूस्ट कॉन्सेप्ट्स 🤶🏻 🃏 👩🏿‍🏭

C ++ में टेम्पलेट्स के उपयोग से, मैं व्यक्तिगत रूप से पैरामीटर प्रतिबंधों की स्थापना के लिए मानक तंत्र की कमी से हमेशा डरता था। दूसरे शब्दों में, जब एक डेवलपर एक फ़ंक्शन लिखता है

template <class T> bool someFunc(T t) { if (t.someCheck()) { t.someAction(0); } }

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

टाइप टी की वस्तुओं को मूल्य से पारित किया जाता है, जिसका अर्थ है कि उनके पास एक खुली प्रतिलिपि निर्माता होना चाहिए
एक सार्वजनिक विधि है T: someCheck जिसमें कोई पैरामीटर नहीं है, जो एक मान लौटाता है जो तार्किक प्रकार में परिवर्तित हो जाता है
एक खुली विधि T :: someAction है , जो एक पैरामीटर ले सकता है जिसे संख्या प्रकार में परिवर्तित किया जा सकता है

समस्या

अब, मान लें कि प्रोग्रामर ने लाइब्रेरी के रूप में someFunc वितरित करने का निर्णय लिया है। इसका उपयोगकर्ता मौजूदा प्रतिबंधों के बारे में कैसे पता लगा सकता है?

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

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

आइए एक उदाहरण पर विचार करें (हम इसे बाद में वापस करेंगे)

आपको सूची (मानक कंटेनर) को क्रमबद्ध करने की आवश्यकता है। कुछ भी नहीं, हम लिखते हैं

 std::list<int>theList; std::sort(theList.begin(), theList.end());

संकलित नहीं। VS2013 में, त्रुटि निम्नानुसार है

त्रुटि C2784: 'अज्ञात-प्रकार std :: ऑपरेटर - (std :: Move_iterator <_RanIt> &, const std :: Move_iterator <_RanIt2> &)': 'std :: Move_iterator <_RanIt> &' के लिए टेम्पलेट तर्क को कम नहीं कर सकता 'std :: _ List_iterator <std :: _ List_val <std :: _ List_simple_types <int> >>' c: \ program files (x86) \ microsoft विजुअल स्टूडियो 12.0 \ vcc के शामिल \ एल्गोरिथ्म 3157 1 MyApp

लेकिन यह इतना बुरा नहीं है - जब आप गलती से क्लिक करते हैं, तो हम खुद को यहीं मानक एल्गोरिथ्म लाइब्रेरी की गहराई में पाते हैं

 template<class _RanIt, class _Pr> inline void sort(_RanIt _First, _RanIt _Last, _Pr _Pred) { // order [_First, _Last), using _Pred _DEBUG_RANGE(_First, _Last); _DEBUG_POINTER(_Pred); _Sort(_Unchecked(_First), _Unchecked(_Last), _Last - _First, _Pred); }

पहली प्रतिक्रिया: “क्या! वेक्टर को क्यों सॉर्ट किया गया था, लेकिन सूची में अचानक ऐसा नहीं हुआ - दोनों कंटेनरों में पुनरावृत्तियाँ हैं, दोनों तत्वों के आदेश के बारे में जानते हैं। "ठीक है, मानक पुस्तकालय ठीक है - यह उदाहरण पीटा गया है, और प्रोग्रामर आमतौर पर जानते हैं कि क्या हुआ। लेकिन कल्पना कीजिए कि आप एक जीवनदान के बिना एक और प्रसिद्ध पुस्तकालय में फेंक दिए गए, न कि इतना प्रसिद्ध पुस्तकालय ...

निर्णय

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

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

बूस्ट का उपयोग करते हुए, डेवलपर हर बार खरोंच से अवधारणाओं का निर्माण करने के लिए बाध्य नहीं है - पुस्तकालय में पूर्वनिर्मित बुनियादी प्रतिबंध शामिल हैं ।

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

 #include <boost/concept_check.hpp> template <class T> struct SomeFuncAppropriate { public: BOOST_CONCEPT_ASSERT((boost::CopyConstructible<T>)); BOOST_CONCEPT_USAGE(SomeFuncAppropriate) { bool b = t.someCheck();//  someCheck,   ,   bool t.someAction(0);//  someAction  ,    } private: T t; // must be data members };

तो, बढ़ावा देने की अवधारणा एक टेम्पलेट संरचना है, जिसका पैरामीटर परीक्षण किया गया प्रकार है। तैयार अवधारणाओं के अनुपालन की जाँच मैक्रो BOOST_CONCEPT_ASSERT का उपयोग करके की जाती है। कृपया ध्यान दें - एक पैरामीटर के रूप में, कोष्ठक में अवधारणा उसके पास जाती है, परिणामस्वरूप, डबल ब्रैकेट की आवश्यकता होती है, हालांकि वे आंख को चोट पहुंचाते हैं।

कस्टम चेक मैक्रो BOOST_CONCEPT_USAGE का उपयोग करके लागू किया जा सकता है। यह याद रखना महत्वपूर्ण है कि परीक्षण में शामिल सभी उदाहरणों (हमारे पास टी टी ) को कक्षा के सदस्यों के रूप में घोषित किया जाना चाहिए , न कि अन्य चर के रूप में।

जब एक अवधारणा घोषित की जाती है, तो इसे उसी मैक्रो BOOST_CONCEPT_ASSERT का उपयोग करके अनुपालन के लिए जांचा जा सकता है। मान लीजिए कि हमारे पास एक वर्ग है

 class SomeClass { public: SomeClass(); void someCheck(); int someAction(int); private: SomeClass(const SomeClass& other); };

आप इसे इस तरह से टेस्ट कर सकते हैं

 BOOST_CONCEPT_ASSERT((SomeFuncAppropriate<SomeClass>));

हम दौड़ने की कोशिश करते हैं - हमें तुरंत एक त्रुटि मिलती है

C2440 त्रुटि: 'आरंभीकरण': 'शून्य' से 'बूल' में परिवर्तित नहीं हो सकता

और जब आप उस पर क्लिक करते हैं, तो हम SomeFuncApp उपयुक्त अवधारणा (BOOST_CONCEPT_USAGE में) की परिभाषा में टूटी हुई रेखा पर फेंक दिए जाते हैं, जहां आप समस्या के कारण को आसानी से समझ सकते हैं - someCun विधि बूल के बजाय शून्य देता है। ठीक करता है, फिर से प्रयास करें ...

C2248 त्रुटि: 'SomeClass :: SomeClass': कक्षा में घोषित निजी सदस्य तक पहुँच नहीं सकता है 'SomeClass' boost \ concept_check.hpp

त्रुटि पर क्लिक करके हम खुद को अवधारणा के स्रोत कोड में पाते हैं

  BOOST_concept(CopyConstructible,(TT)) { BOOST_CONCEPT_USAGE(CopyConstructible) { TT a(b); // require copy constructor TT* ptr = &a; // require address of operator const_constraints(a); ignore_unused_variable_warning(ptr); } ...

और कर्सर लाइन की ओर इशारा करता है

  TT a(b); // require copy constructor

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

चलिए वापस std :: list Sorting उदाहरण पर std :: सॉर्ट का उपयोग करते हैं। हम एक अवधारणा के रूप में सॉर्टेबल कंटेनर के लिए आवश्यकताओं को व्यक्त करते हैं। सबसे पहले, एसटीडी :: सॉर्ट केवल उन कंटेनरों के साथ काम कर सकता है जो यादृच्छिक पहुंच का समर्थन करते हैं। इसी अवधारणा को बढ़ावा देने ( बढ़ावा :: randomAccessContainer ) में है, लेकिन यह पर्याप्त नहीं है। कंटेनर की सामग्री के लिए एक आवश्यकता भी है - इसके तत्वों को तुलना ऑपरेटर का समर्थन करना चाहिए "कम।" यहाँ बढ़ावा फिर से बढ़ावा देने के लिए तैयार अवधारणा के साथ मदद करता है :: LessThanComparable ।
हम अवधारणाओं को एक में जोड़ते हैं

 template <class T> struct Sortable { public: typedef typename std::iterator_traits<typename T::iterator>::value_type content_type; BOOST_CONCEPT_ASSERT((boost::RandomAccessContainer<T>)); BOOST_CONCEPT_ASSERT((boost::LessThanComparable<content_type>)); };

परीक्षण चलाएं

 BOOST_CONCEPT_ASSERT((Sortable<std::list<int> >));

हम देखते हैं

त्रुटि C2676: बाइनरी '[': 'const std :: list <int, std :: एलोकेटर <_Ty >>' इस ऑपरेटर को परिभाषित नहीं करता है या पूर्वनिर्धारित ऑपरेटर बूस्ट \ concept_check.hpp के लिए स्वीकार्य एक प्रकार के लिए रूपांतरण

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

 BOOST_CONCEPT_ASSERT((Sortable<std::vector<SomeClass> >));

कंटेनर अब उपयुक्त है, लेकिन इसे सॉर्ट करना अभी भी असंभव है, क्योंकि SomeClass कम-से-कम ऑपरेटर को परिभाषित नहीं करता है। हम तुरंत इसके बारे में जान जाएंगे

C2676 त्रुटि: बाइनरी '<': 'SomeClass' इस ऑपरेटर को परिभाषित नहीं करता है या पूर्वनिर्धारित ऑपरेटर को एक प्रकार के रूपांतरण को बढ़ाता है \ _ \ _

त्रुटि पर एक क्लिक - और हम अपने आप को स्रोत कोड LessThanComparable में पाते हैं, यह महसूस करते हुए कि वास्तव में उन्होंने क्या उल्लंघन किया है।

इस प्रकार, अवधारणाएं C ++ में सामान्यीकृत प्रोग्रामिंग को थोड़ा कम चरम बनाती हैं। खुशी के सिवा और क्या नहीं मिल सकता!

बूस्ट कॉन्सेप्ट्स

समस्या

निर्णय

More articles: