पिम्पल माय पिम्पल का अनुवाद, भाग 2

लेख के पहले भाग में, सम्मानित skb7 द्वारा अनुवादित, Pimpl मुहावरे (कार्यान्वयन के लिए सूचक), इसके उद्देश्य और फायदे की जांच की गई थी। दूसरे भाग में, हम इस मुहावरे का उपयोग करते समय आने वाली समस्याओं पर विचार करेंगे, और उन्हें हल करने के लिए कुछ विकल्प भी सुझाएंगे।

मूल के लिंक

यह हाइज डेवलपर वेबसाइट पर प्रकाशित एक लेख के दूसरे भाग का अनुवाद है। पहले भाग का अनुवाद यहाँ पाया जा सकता है । दोनों भागों के मूल (जर्मन में) यहाँ और यहाँ हैं ।

अनुवाद एक अंग्रेजी अनुवाद से किया गया था।

अमूर्त

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

भाग २

लगातार उल्लंघन

पहला अति सूक्ष्म अंतर, जो स्पष्ट रूप से दूर है, वस्तु के क्षेत्रों की स्थिरता की व्याख्या से संबंधित है। Pimpl मुहावरे का उपयोग करते समय, विधियाँ d सूचक के माध्यम से कार्यान्वयन वस्तु के क्षेत्रों तक पहुँच प्राप्त करती हैं:

 SomeThing & Class::someThing() const { return d->someThing; } 

इस उदाहरण की सावधानीपूर्वक जांच करने के बाद, आप देख सकते हैं कि यह कोड C ++ में निरंतर वस्तुओं की सुरक्षा के लिए तंत्र को someThing() देता है: चूंकि विधि को someThing() घोषित किया गया है, कुछ someThing() प्रकार someThing() विधि के अंदर this सूचक प्रकार const Class * , और सूचक d क्रमशः, प्रकार Class::Private * const । यह, हालांकि, Class::Private वर्ग से फ़ील्ड तक पहुँच को संशोधित करने से रोकने के लिए पर्याप्त नहीं है d हालांकि d हालांकि स्थिर है, लेकिन *d नहीं है।

याद रखें: C ++ में, const संशोधक की स्थिति मायने रखती है:

 const int * pci; //    int int * const cpi; //    int const int * const cpci; //     int *pci = 1; // : *pci  *cpi = 1; // : *cpi   *cpci = 1; // : *cpci  int i; pci = &i; //  cpi = &i; // : cpi  cpci = &i; // : cpci  

इस प्रकार, पिंपल मुहावरे का उपयोग करते समय, सभी तरीके (और जिन्हें const घोषित किया गया है) कार्यान्वयन ऑब्जेक्ट के फ़ील्ड को संशोधित कर सकते हैं। यदि हमने पिम्पल का उपयोग नहीं किया होता, तो संकलक ऐसी त्रुटियों को पकड़ने में सक्षम होता।

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

 template <typename T> class deep_const_ptr { T * p; public: explicit deep_const_ptr( T * t ) : p( t ) {} const T & operator*() const { return *p; } T & operator*() { return *p; } const T * operator->() const { return p; } T * operator->() { return p; } }; 

operator*() और operator->() विधियों के निरंतर और नियमित संस्करणों को ओवरलोड करने के साथ चाल का उपयोग करके, *d ऑब्जेक्ट पर d पॉइंटर निरंतर को लागू करना संभव है। Private *d जगह deep_const_ptr<Private> d पूरी तरह से प्रश्न में समस्या को हल करता है। लेकिन इस तरह का एक समाधान बेमानी हो सकता है: इस स्थिति में, ओवररिपिंग डेरेफेरेंस ऑपरेटर्स के साथ चाल को सीधे Class लागू किया जा सकता है:

 class Class { // ... private: const Private * d_func() const { return _d; } Private * d_func() { return _d; } private: Private * _d; }; 

अब, पद्धति कार्यान्वयन में _d का उपयोग करने के बजाय, आपको d_func() को कॉल करना चाहिए:

 void Class::f() const { const Private * d = f_func(); //  'd' ... } 

बेशक, कुछ भी तरीकों में _d सीधी पहुंच को रोकता है, जो कि स्मार्ट पॉइंटर deep_const_ptr का उपयोग करते समय नहीं होगा। इसलिए, Class के ओवरलोडिंग के तरीके को डेवलपर से अधिक अनुशासन की आवश्यकता होती है। इसके अलावा, deep_const_ptr वर्ग के क्रियान्वयन को Class ऑब्जेक्ट के नष्ट होने पर बनाई गई Private वस्तु को स्वचालित रूप से हटाने के लिए संशोधित किया जा सकता है। बदले में, कक्षा के तरीकों को ओवरलोड करना बहुरूपी वर्गों की पदानुक्रम बनाने में उपयोगी है, जिसे बाद में प्रदर्शित किया जाएगा।

कंटेनर क्लास तक पहुंच

निम्नलिखित बाधा तब उत्पन्न होती है जब डेवलपर Class सभी private तरीकों को private वर्ग में रखता है: अब इन विधियों में आप Class अन्य (गैर- static ) तरीकों को कॉल नहीं कर सकते हैं, क्योंकि कनेक्शन Class -> Private यूनिडायरेक्शनल है:

 class Class::Private { public: Private() : ... {} // ... void callPublicFunc() { /*???*/Class::publicFunc(); } }; Class::Class() : d( new Private ) {} 

इस समस्या को एक बैकलिंक ( q क्षेत्र का क्यू कोड में उल्लेख किया गया है) को पेश करके हल किया जा सकता है:

 class Class::Private { Class * const q; //   public: explicit Private( Class * qq ) : q( qq ), ... {} // ... void callPublicFunc() { q->publicFunc(); } }; Class::Class() : d( new Private( this ) ) {} 

Backreference का उपयोग करते समय, यह याद रखना महत्वपूर्ण है कि Private निर्माणकर्ता के काम करने तक d इनिशियलाइज़ेशन पूरा नहीं हुआ था। डेवलपर को Private निर्माणकर्ता के शरीर में d फ़ील्ड तक पहुंचने वाले Class तरीकों को कॉल नहीं करना चाहिए, अन्यथा उसे अपरिभाषित व्यवहार मिलेगा।

पुनर्बीमा के लिए, डेवलपर को एक बैकल पॉइंटर के साथ बैकलिंक को इनिशियलाइज़ करना होगा, और Class कंस्ट्रक्टर के शरीर में, Private कंस्ट्रक्टर को काम करने के बाद ही सही लिंक वैल्यू सेट करना होगा:

 class Class::Private { Class * const q; // back-link public: explicit Private( /*Class * qq*/ ) : q( 0 ), ... {} // ... }; Class::Class() : d( new Private/*( this )*/ ) { //   : d->q = this; } 

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

उप-योगों

अब जब हम Pimpl मुहावरे द्वारा निजी कार्यान्वयन वर्ग की शुरूआत के साथ खो गई कार्यक्षमता को पुनर्स्थापित करने में कामयाब रहे हैं, तो शेष लेख कुछ "जादू" के लिए समर्पित होगा जो हमें अतिरिक्त स्मृति लागतों को समतल करने की अनुमति देगा जो कि Pimpl मुहावरे का उपयोग करते समय उत्पन्न होती हैं।

पुन: प्रयोज्य वस्तुओं के साथ प्रदर्शन में सुधार

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

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

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

डेवलपर इनहेरिट करने वाली कक्षाओं में बेस क्लास के d पॉइंटर का पुन: उपयोग करके d d पॉइंटर्स (और संबद्ध मेमोरी आवंटन) की संख्या में वृद्धि से निपट सकता है:

 // base.h: class Base { // ... public: Base(); protected: class Private; explicit Base( Private * d ); Private * d_func() { return _d; } const Private * d_func() const { return _d; } private: Private * _d; }; // base.cpp: Base::Base() : _d( new Private ) { // ... } Base::Base( Private * d ) : _d( d ) { // ... } 

सार्वजनिक निर्माणकर्ताओं के अतिरिक्त protected कंस्ट्रक्टर की मौजूदगी से वर्ग को बेस क्लास में अपने d पॉइंटर को एम्बेड करने की अनुमति मिलती है। कोड भी const लिए विरासत वाले वर्गों की (गैर-संशोधित) पहुंच के लिए d_func() विधियों (जो अब protected ) का उपयोग करके एक const शुद्धता फिक्स का उपयोग करता है।

 // derived.h: class Derived : public Base { public: Derived(); // ... protected: class Private; Private * d_func(); //    const Private * d_func() const; //  }; // derived.cpp: Derived::Private * Derived::d_func() { return static_cast<Private*>( Base::d_func() ); } const Derived::Private * Derived::d_func() const { return static_cast<const Private*>( Base::d_func() ); } Derived::Derived() : Base( new Private ) {} 

अब, Derived लेखक Derided::Private बजाय Base::Private to Base::_d (विभिन्न संदर्भों में समान Private नाम के उपयोग पर ध्यान दें) पास करने के लिए नए Base कंस्ट्रक्टर का उपयोग करता है। लेखक Base विधियों के रूप में अपने d_func() विधियों को जबरन रूपांतरण के साथ लागू करता है।

Base कंस्ट्रक्टर के सही ढंग से काम करने के लिए, Base::Private का पूर्वज होना आवश्यक है Derived::Private :

 class Derived::Private : public Base::Private { // ... }; 

Base::Private से वास्तव में एक वर्ग प्राप्त करने के लिए, तीन शर्तों को पूरा करना होगा।

सबसे पहले, डेवलपर को Base::Private बनाना चाहिए Base::Private विध्वंसक आभासी। अन्यथा, Base विध्वंसक ट्रिगर होने पर अपरिभाषित व्यवहार होगा, जो Base::Private लिए एक पॉइंटर के माध्यम से Derived::Private कार्यान्वयन ऑब्जेक्ट को हटाने का प्रयास करेगा।

दूसरे, डेवलपर को एक ही पुस्तकालय में दोनों वर्गों को लागू करना होगा, क्योंकि Private आमतौर पर निर्यात तालिका में नहीं आता है - वे विंडोज पर declspec(dllexport) में निर्दिष्ट नहीं हैं, और visibility=hidden ELF बायनेरिज़ में visibility=hidden रूप में सूचीबद्ध नहीं हैं। हालाँकि, निर्यात अपरिहार्य है यदि Base और Derived विभिन्न पुस्तकालयों में लागू किए Derived । असाधारण मामलों में, पुस्तकालय के मुख्य वर्गों के Private वर्गों का निर्यात किया जाता है: उदाहरण के लिए, नोकिया डेवलपर्स ने QObjectPrivate (QtCore से) और QWidgetPrivate (QtGui से) कक्षाओं का निर्यात किया, जो बहुत लोकप्रिय हैं, क्योंकि QObject और QWidget से विरासत में मिले अन्य मॉड्यूल से बहुत सारे वर्ग। हालांकि, ऐसा करने में, डेवलपर्स न केवल इंटरफ़ेस स्तर पर, बल्कि " libQtGui.so.4.5.0 " स्तर पर पुस्तकालयों के बीच निर्भरता बनाते हैं, इस प्रकार विभिन्न संस्करणों के पुस्तकालयों की संगतता का उल्लंघन करते हैं: सामान्य मामले में, libQtGui.so.4.5.0 गतिशील नहीं होने पर काम नहीं करेगा लिंकर इसमें libQtCore.so.4.6.0 कनेक्ट करेगा।

और अंत में, तीसरा, Base::Private की परिभाषा अब बेस क्लास base.cpp फाइल ( base.cpp ) में छिपी नहीं रह सकती है, क्योंकि Derived::Private की परिभाषा की आवश्यकता है। तो Base::Private की परिभाषा को कहां रखा जाए Base::Private ? आप इसे बस base.h में शामिल कर सकते हैं, लेकिन फिर Pimpl का उपयोग क्या है यदि आंतरिक कार्यान्वयन अभी भी बाहर से दिखाई दे रहा है? इन सवालों का जवाब एक विशेष, निजी हेडर फ़ाइल बनाना है। इस उद्देश्य के लिए, Qt और KDE ने _p.h (प्रत्यय _priv , _i और _impl भी _impl ) के लिए एक नामकरण योजना स्थापित की है। Base::Private को परिभाषित करने के अलावा Base::Private , यह निजी फ़ाइल Base विधियों के inline कार्यान्वयन की मेजबानी कर सकती है, उदाहरण के लिए, निर्माणकर्ता:

 inline Base::Base( Private * d ) : _d( d ) {} 

और derived_p.h :

 inline Derived::Derived( Private * d ) : Base( d ) {} inline const Derived::Private * Derived::d_func() const { return static_cast<const Private*>( Base::d_func() ); } inline Derived::Private * Derived::d_func() { return static_cast<Private*>( Base::d_func() ); } 

सख्ती से बोलना, उपरोक्त कोड वन डेफिनिशन रूल नियम के विरुद्ध है, क्योंकि d_func() कार्यान्वयन फ़ाइलों में इनलाइन हैं जो derived_p.h , और अन्य फ़ाइलों में इनलाइन नहीं हैं।

व्यवहार में, यह कोई समस्या नहीं है, क्योंकि जो कोई भी d_func() को d_func() है, उसे किसी भी तरह से derived_p.h को शामिल करना derived_p.h । पुनर्बीमा के लिए, आप Derived परिभाषा में inline रूप में समस्याग्रस्त तरीकों की घोषणा कर सकते हैं। फाइल में Derived परिभाषा - आधुनिक कंपाइलर कार्यान्वयन के बिना तरीकों में inline अनुमति देते हैं।

अक्सर, डेवलपर्स निरर्थक कोड को छिपाते हैं जो मैक्रोज़ के तहत इस तकनीक के साथ होता है। उदाहरण के लिए, Qt वर्ग परिभाषाओं में उपयोग के लिए मैक्रो Q_DECLARE_PRIVATE को परिभाषित करता है, और मैक्रो Q_D , जो कि विधि कार्यान्वयन में पॉइंटर d घोषित करता है और इसे d_func() साथ आरंभ करता है।

एक खामी फिर भी बनी हुई है: यदि डेवलपर कार्यान्वयन पॉइंटर और बैकलिंक तंत्र के पुन: उपयोग को जोड़ना चाहता है, तो कुछ कठिनाइयां उत्पन्न होती हैं। विशेष रूप से, देखभाल को नहीं किया जाना चाहिए (यहां तक ​​कि स्पष्ट रूप से भी!) सूचक को Derived करने के लिए, जिसे Private निर्माणकर्ता को विरासत के पदानुक्रम कार्य में कंस्ट्रक्टर तक पारित किया जाता है।

 Derived::Private( Derived * qq ) : Base( qq ) // ,   { q->setFoo( ... ); // ,     } 

न केवल Derived की अवधि के दौरान dereferencing पर बनाया Derived , लेकिन यह भी - और यह पहले से वर्णित गैर-पॉलीफ़ॉर्मल मामले से अंतर है - Base , क्योंकि इसका Private क्षेत्र अभी भी बनाया जा रहा है।

इस मामले में, पहले की तरह, आपको एक null सूचक के साथ पिछड़े लिंक को इनिशियलाइज़ करना चाहिए। बैकवर्ड लिंक को सही मान पर सेट करने का कार्य उस श्रेणी के साथ रहता है, जो पदानुक्रमित श्रृंखला के अंत में निहित होती है, अर्थात वह वर्ग जो अपने Private वर्ग को पदानुक्रम में लागू करता है। Derived के मामले में, कोड इस तरह दिखेगा:

 Derived::Derived() : Base( new Private/*( this )*/ ) { d_func()->_q = this; } 

यदि वांछित है, तो डेवलपर एक अलग विधि Private::init() (जिसका अर्थ है दो चरणों में Private निर्माण Private::init() माध्यम से, एक पिछड़े लिंक के माध्यम से पहुंच की आवश्यकता है, आरंभीकरण कोड को स्थानांतरित कर सकता है। इस विधि को वर्ग के निर्माता में (केवल) कहा जाता है, जो स्वयं Derived का एक उदाहरण बनाता है।

 Derived::Derived( Private * d ) : Base( d ) { // __  d->init()! } Derived::Derived() : Base( new Private ) { d_func()->init( this ); } Derived::Private::init( Derived * qq ) { Base::Private::init( qq ); //  _q //    } 

इसके अलावा, प्रत्येक Private वर्ग के पास कंटेनर वर्ग का अपना स्वयं का बैकवर्ड संदर्भ होना चाहिए, या q_func() विधियों को परिभाषित करना चाहिए जो Base::Private बेस क्लास के पिछड़े संदर्भ के प्रकार रूपांतरण के लिए जिम्मेदार होंगे। संबंधित कोड यहां नहीं दिया गया है - यह लिखना एक सम्मानित पाठक के लिए एक अभ्यास के रूप में रहता है। इस अभ्यास का समाधान हेइज़ एफ़टीपी सर्वर पर "पंप" ¹ Shape पदानुक्रम के रूप में पाया जा सकता है।

निष्कर्ष

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

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

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

सूत्रों का कहना है

• जॉन लैक्स; बड़े पैमाने पर सी ++ सॉफ्टवेयर डिजाइन; एडिसन-वेस्ले लॉन्गमैन, 1996
• जड़ी बूटी सटर; असाधारण सी ++: 47 इंजीनियरिंग पहेलियाँ, प्रोग्रामिंग समस्याएं, और समाधान; एडिसन-वेस्ले लॉन्गमैन, 2000
• हर्ब सटर, आंद्रेई अलेक्जेंड्रेस्कु: सी ++ कोडिंग मानक: 101 नियम, दिशानिर्देश और सर्वोत्तम अभ्यास; एडिसन-वेस्ले लॉन्गमैन, 2004
• मार्क मुत्ज़; मेरे पिंपल को पिंपल करें; C ++: Vor- und Nachteile des d-Zeiger-Idioms, Teil 1; Artikel auf heise डेवलपर ( अंग्रेज़ी अनुवाद उपलब्ध )

अनुवादक के नोट्स

¹ इसके बाद: शब्दों पर एक नाटक - पिम्पल क्रिया के साथ दलाल के साथ व्यंजन है, जो टेलीविजन शो "पिम्प माय राइड" (अंग्रेजी "पिम्प माय राइड") का एक संदर्भ है।