संकलन त्रुटि। संरचना

Question

के साथ गुणों का उपयोग करना कृपया संरचना निर्माता पर निम्न त्रुटि की व्याख्या करें। यदि मैं कक्षा पर संरचना बदलता हूं तो त्रुटियां चली जाती हैं।

public struct DealImportRequest 
{ 
    public DealRequestBase DealReq { get; set; } 
    public int ImportRetryCounter { get; set; } 

    public DealImportRequest(DealRequestBase drb) 
    { 
     DealReq = drb; 
     ImportRetryCounter = 0; 
    } 
} 

• त्रुटि CS0188: 'इस' वस्तु से पहले अपने क्षेत्रों के सभी
• त्रुटि CS0843 करने के लिए आवंटित कर रहे हैं नहीं किया जा सकता: स्वचालित रूप से लागू किया संपत्ति 'DealImportRequest.DealReq' के लिए बैकअप क्षेत्र पूरी तरह से सौंपा जाना चाहिए कॉलर को नियंत्रण वापस करने से पहले। एक निर्माता प्रारंभकर्ता से डिफ़ॉल्ट कन्स्ट्रक्टर को कॉल करने पर विचार करें।

Answer 1

त्रुटि संदेश अनुशंसा करता है, तो आप डिफॉल्ट कन्स्ट्रक्टर को कन्स्ट्रक्टर प्रारंभकर्ता से कॉल करके इसे हल कर सकते हैं।

public DealImportRequest(DealRequestBase drb) : this() 
{ 
    DealReq = drb; 
    ImportRetryCounter = 0; 
} 

भाषा विनिर्देश से:

10.7.3 स्वचालित रूप से लागू किया गुण

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

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

ध्यान दें कि आपके पास मौजूद संरचना उत्परिवर्तनीय है। This is not recommended। मेरा सुझाव है कि आप या तो एक वर्ग टाइप करें (आपकी संकलन समस्याओं को तुरंत दूर जाना चाहिए) या प्रकार अपरिवर्तनीय बनाओ। इसे पूरा करने का सबसे आसान तरीका, आपके द्वारा प्रस्तुत कोड को मानना ​​संपूर्ण संरचना है, जो सेटर्स को निजी (get; private set;) बनाना होगा। बेशक, आपको यह भी सुनिश्चित करना चाहिए कि आप संरचना में किसी भी उत्परिवर्तन विधियों को बाद में नहीं जोड़ते हैं जो फ़ील्ड को संशोधित करने के लिए निजी पहुंच पर भरोसा करते हैं। वैकल्पिक रूप से, आप गुणों को readonly बैकिंग फ़ील्ड्स के साथ वापस कर सकते हैं और सेटर्स से पूरी तरह से छुटकारा पा सकते हैं।

Answer 2

कोड आपके पास निम्न कोड के बराबर है:

1. स्वत: गुण लागू करता है:

   public struct DealImportRequest 
   { 
       private DealRequestBase _dr; 
       private int _irc; 
       public DealRequestBase DealReq 
       { 
        get { return _dr; } 
        set { _dr = value; } 
       } 
       public int ImportRetryCounter 
       { 
        get { return _irc; } 
        set { _irc = value; } 
       } 
       /* Note we aren't allowed to do this explicitly - this is didactic code only and isn't allowed for real*/ 
       public DealImportRequest() 
       { 
        this._dr = default(DealRequestBase); // i.e. null or default depending on whether this is reference or value type. 
        this._irc = default(int); // i.e. 0 
       } 
       public DealImportRequest(DealRequestBase drb) 
       { 
        this.DealReq = drb; 
        this.ImportRetryCounter = 0; 
       } 
   } 
   

   अब, सभी मैं यहाँ किया है वाक्यात्मक चीनी को हटा है।

2. काम करता है कि कौन से सदस्यों को this के सापेक्ष निपटाया जाता है।
3. सभी struct एक डिफ़ॉल्ट नो-पैरामीटर कन्स्ट्रक्टर देता है।

पहले दो वैकल्पिक हैं (आप उन्हें स्पष्ट रूप से लिख सकता है अगर आप की कामना की) लेकिन तीसरे नहीं है - हम एक struct के parameterless निर्माता के लिए हमारे अपने कोड लिखने की अनुमति नहीं है, हम साथ जाना है एक जो उपरोक्त कोड में से एक जैसा काम करता है, वह स्वचालित रूप से हमें दिया जा रहा है।

अब, यहाँ पर देखा, अचानक दो त्रुटियों का अर्थ स्पष्ट हो जाता है - अपने निर्माता परोक्ष this उपयोग कर रहा है इससे पहले कि यह क्षेत्र (त्रुटि 188) आवंटित कर रहे हैं और उन क्षेत्रों स्वत: गुण (त्रुटि 843) का समर्थन कर होते हैं।

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

public DealImportRequest(DealRequestBase drb) 
    :this() 
{ 
    DealReq = drb; 
    ImportRetryCounter = 0; 
} 

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

Answer 3

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