कन्स्ट्रक्टर और कॉन्स्ट सदस्य चर ले जाएं

Question

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

लेकिन सी ++ 0x चालक कन्स्ट्रक्टर के साथ मैं एक समस्या में भाग लेता हूं। चूंकि विनाशक को "अनलोड" ऑब्जेक्ट पर भी बुलाया जाता है, इसलिए मुझे संसाधन हैंडल की सफाई को रोकने की आवश्यकता है। चूंकि सदस्य चर है, इसलिए मेरे पास विनाशक को इंगित करने के लिए मान -1 या INVALID_HANDLE (या समकक्ष मान) असाइन करने का कोई तरीका नहीं है कि उसे कुछ भी नहीं करना चाहिए।

क्या कोई तरीका है कि किसी ऑब्जेक्ट की स्थिति किसी अन्य ऑब्जेक्ट में स्थानांतरित हो जाने पर विनाशक को नहीं कहा जाता है?

उदाहरण:

class File 
{ 
public: 
    // Kind of "named constructor" or "static factory method" 
    static File open(const char *fileName, const char *modes) 
    { 
     FILE *handle = fopen(fileName, modes); 
     return File(handle); 
    } 

private: 
    FILE * const handle; 

public: 
    File(FILE *handle) : handle(handle) 
    { 
    } 

    ~File() 
    { 
     fclose(handle); 
    } 

    File(File &&other) : handle(other.handle) 
    { 
     // The compiler should not call the destructor of the "other" 
     // object. 
    } 

    File(const File &other) = delete; 
    File &operator =(const File &other) = delete; 
}; 

Answer 1

नहीं, यह करने के लिए कोई रास्ता नहीं है। मैं सुझाव दूंगा कि यदि आप वास्तव में handle परिवर्तनीय होने के साथ जुड़े हुए हैं तो आपके पास एक गैर-कॉन्स ध्वज सदस्य चर होना चाहिए जो इंगित करता है कि विनाश कुछ भी करना चाहिए या नहीं।

Answer 2

एक चालक कन्स्ट्रक्टर को लागू करने का सामान्य तरीका उदाहरण के सदस्यों को शून्य या अन्यथा अमान्य करना है (उदाहरण के लिए MSDN देखें)। इसलिए मैं कहूंगा कि const का उपयोग न करें क्योंकि यह चाल semantics के लक्ष्यों के साथ असंगत है।

Answer 3

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

Answer 4

संदर्भ गणना मानक दृष्टिकोण है जो आपकी समस्या का समाधान करता है। अपनी कक्षा में संदर्भ गिनती जोड़ने पर विचार करें; या तो मैन्युअल रूप से, या मौजूदा टूल्स जैसे boost shared_ptr का उपयोग करना।

Answer 5

असल में, मैंने आज भी इस समस्या को अपने साथ चलाया है। स्वीकार करने के लिए 'नहीं किया जा सकता' & 'उपयोग shared_ptr/संदर्भ गिनती', और अधिक googling के लिए तैयार नहीं है, मैं इस आधार वर्ग के साथ आया था:

class Resource 
{ 
private: 
    mutable bool m_mine; 

protected: 
    Resource() 
    : m_mine(true) 
    { 
    } 

    Resource(const Resource&)  = delete; 
    void operator=(const Resource&) = delete; 

    Resource(const Resource&& other) 
    : m_mine(other.m_mine) 
    { 
     other.m_mine = false; 
    } 

    bool isMine() const 
    { 
     return m_mine; 
    } 
}; 

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

class A : protected Resource 
{ 
private: 
    const int m_i; 

public: 
    A() 
    : m_i(0) 
    { 
    } 

    A(const int i) 
    : m_i(i) 
    { 
    } 

    A(const A&& a) 
    : Resource(std::move(a )) 
    , m_i  (std::move(a.m_i)) // this is a move iff member has const move constructor, copy otherwise 
    { 
    } 

    ~A() 
    { 
     if (isMine()) 
     { 
      // Free up resources. Executed only for non-moved objects 
      cout << "A destructed" << endl; 
     } 
    } 
}; 

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

struct B 
{ 
    const A m_a; 
    const X m_x; 

    B(const A&& a, const X& x) // implement this way only if X has copy constructor; otherwise do for 'x' like we do for 'a' 
    : m_a(std::move(a)) 
    , m_x(   x ) 
    { 
    } 

    B(const B&& b) 
    : m_a(std::move(b.m_a)) 
    , m_x(std::move(b.m_x)) // this is a move iff X has move constructor, copy otherwise 
    { 
    } 

    ~B() 
    { 
     cout << "B destructed" << endl; 
    } 
}; 

ध्यान दें कि बी के क्षेत्र भी स्थिरांक हो सकता है:

फिर, यह सोचते हैं कि आप एक struct X है। हमारे चालक रचनाकार हैं। आपके प्रकारों को उचित चालक रचनाकारों को देखते हुए, किसी भी ढेर-आवंटित स्मृति को वस्तुओं के बीच साझा किया जा सकता है।