सी ++ में उपयोग करने के लिए गेटर और सेटर, पॉइंटर्स या संदर्भ, और अच्छा वाक्यविन्यास?

Question

मैं सी ++ गेटर्स और सेटर्स के लिए एक अच्छा वाक्यविन्यास जानना चाहता हूं।

void Member(YourClass *value){ 
    this->pMember = value; // forget about deleting etc 
} 

और गेटर:

private: 
YourClass *pMember; 

सेटर मुझे लगता है कि आसान है? क्या मुझे संदर्भ या कॉन्स्ट पॉइंटर्स का उपयोग करना चाहिए?

उदाहरण:

YourClass &Member(){ 
    return *this->pMember; 
} 

या

YourClass *Member() const{ 
    return this->member; 
} 

क्या उन दोनों के बीच क्या अंतर है?

धन्यवाद,

जो

संपादित करें:

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

तो

मुझे लगता है मैं संदर्भ

बजाय स्थिरांक संकेत का उपयोग करेगा

कॉन्स्ट पॉइंटर्स को हटाया या सेट नहीं किया जा सकता है, है ना?

Answer 1

एक सामान्य कानून के रूप में:

• अगर शून्य एक वैध पैरामीटर या वापसी मान, उपयोग संकेत दिए गए है।
• यदि NULL मान्य पैरामीटर या वापसी मान नहीं है, तो संदर्भों का उपयोग करें।

तो अगर सेटटर को संभवतः न्यूल के साथ बुलाया जाना चाहिए, तो पैरामीटर के रूप में एक सूचक का उपयोग करें। अन्यथा एक संदर्भ का उपयोग करें।

यदि यह एक नल पॉइंटर वाले ऑब्जेक्ट के गेटर को कॉल करने के लिए मान्य है, तो उसे एक पॉइंटर वापस करना चाहिए। यदि ऐसा मामला एक अवैध आविष्कार है, तो वापसी मूल्य एक संदर्भ होना चाहिए। अगर सदस्य परिवर्तक नल है तो गेटटर को अपवाद फेंकना चाहिए।

Answer 2

उनके बीच क्या अंतर है?

संदर्भ बात का अन्य नाम है (यह बात है *)। एक सूचक बात का पता है। यदि कोई मौका है कि जो इंगित किया गया है वह वहां नहीं होगा, तो शायद आप संदर्भ वापस नहीं करना चाहते हैं। संदर्भ कॉलर को बताते हैं "मैं आपको एक उपनाम देने जा रहा हूं जो आपके पास वापस आने पर अस्तित्व में रहेगा"। असल में यह देखने के लिए वास्तव में कोई तरीका नहीं है कि क्या अंतर्निहित है वैध है या नहीं।

पॉइंटर के साथ, अर्थात्, आप यह कह रहे हैं कि कॉलर यह देखने के लिए जांच कर सकता है कि सदस्य इसका उपयोग करने से पहले मौजूद है या नहीं। आम तौर पर यह एक पूर्ण जांच के साथ किया जाता है।

आखिरकार कोई "सही" उत्तर नहीं है। यह कक्षा के अनुबंध पर निर्भर करता है और यदि कॉलर यह जांचना चाहता/चाहती है कि "सदस्य" अभी भी आसपास है या नहीं।

संक्षिप्त उत्तर उन चीज़ों के लिए पॉइंटर्स है जिन्हें कहीं और और "असीमित" उपनामों के संदर्भों के लिए संदर्भित किया जा सकता है।

Answer 3

सबसे अच्छी बात यह है कि क्लाइंट को वास्तविक ओओ इंटरफ़ेस प्रदान करना है जो कार्यान्वयन विवरण छुपाता है। गेटर्स और सेटर्स ओओ नहीं हैं।

Answer 4

+1 सेटर्स और गेटर्स के उपयोग पर सवाल पूछने पर +1। यदि आपको उनका उपयोग करना चाहिए और बूस्ट :: shared_ptr का उपयोग करने पर विचार करने की संभावना है। इस तरह स्वामित्व आपके लिए संभाला जाता है।

Answer 5

जैसा कि अन्य ने कहा है, अगर नल संभावना है तो पॉइंटर्स का उपयोग करें।

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

(और हाँ, मैं आमतौर पर स्मार्ट संकेत का उपयोग करें। उन मेरे मन में संदर्भ के लिए समान हैं। मैं यहाँ से कम स्तर कोड के बारे में बात कर रहा हूँ।)

Answer 6

जोनाथन, क्या संकलक आप उपयोग कर रहे हैं? एक शानदार मौका है कि shared_ptr संकलक के TR1 कार्यान्वयन के हिस्से के रूप में पहले ही इसके साथ भेज दिया जाता है।

Answer 7

आपका कोड एक बहुत अच्छा लगता है जैसे कि आप एक अलग भाषा के आदी हैं - सी ++ में this->x (एक उदाहरण के लिए) का उपयोग अपेक्षाकृत असामान्य है। जब कोड अच्छी तरह से लिखा जाता है, तो एक एक्सेसर या म्यूटेटर का उपयोग कर रहा है।

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

कब/यदि आपको नियंत्रित करने की आवश्यकता है कि कौन सा मान असाइन किया गया है, तो ऑपरेटर ओवरलोडिंग आपको क्लाइंट कोड पर बदसूरत/सेट सिंटैक्स को मजबूर किए बिना उस नियंत्रण को लेने देता है। विशेष रूप से, आप जो चाहते हैं वह प्रॉक्सी क्लास (या क्लास टेम्पलेट) है। सिर्फ एक उदाहरण के लिए, सबसे सामान्य परिस्थितियों में से एक जहां लोग प्राप्त/सेट फ़ंक्शंस चाहते हैं, वह ऐसी संख्या की तरह है जो किसी विशेष सीमा तक सीमित होना चाहिए। setXXX सीमा में होने के लिए नए मान की जांच करता है, और getXXX मान देता है।

आपको लगता है कि, एक (काफी) सरल टेम्पलेट काम और अधिक सफाई से कर सकते हैं चाहते हैं:

template <class T, class less=std::less<T> > 
class bounded { 
    const T lower_, upper_; 
    T val_; 

    bool check(T const &value) { 
     return less()(value, lower_) || less()(upper_, value); 
    } 

    void assign(T const &value) { 
     if (check(value)) 
      throw std::domain_error("Out of Range"); 
     val_ = value; 
    } 

public: 
    bounded(T const &lower, T const &upper) 
     : lower_(lower), upper_(upper) {} 

    bounded(bounded const &init) 
     : lower_(init.lower), upper_(init.upper) 
    { 
     assign(init); 
    } 

    bounded &operator=(T const &v) { assign(v); return *this; } 

    operator T() const { return val_; } 

    friend std::istream &operator>>(std::istream &is, bounded &b) { 
     T temp; 
     is >> temp; 

     if (b.check(temp)) 
      is.setstate(std::ios::failbit); 
     else 
      b.val_ = temp; 
     return is; 
    } 
}; 

यह भी कोड बहुत स्वयं कुछ दस्तावेज़ीकृत के करीब बना देता है - उदाहरण के लिए, जब आप एक वस्तु की घोषणा जैसे: bounded<int>(1, 1024);, यह तुरंत स्पष्ट है कि इरादा 1 से 1024 की सीमा में एक पूर्णांक है। केवल एक ही भाग प्रश्न के लिए खुलासा यह है कि श्रेणी में 1 और/या 1024 शामिल है या नहीं।कक्षा में एक इंटीरियर को परिभाषित करने से यह काफी अलग है, और उम्मीद है कि कक्षा में कभी भी यह देखने के लिए कि वे कुछ को (उस बिंदु पर अज्ञात) लागू करने के लिए सेटXXक्स का उपयोग करना चाहते हैं, जो मूल्यों पर सीमाओं के सेट हो सकते हैं सौंपा।

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

Answer 8

अन्य उत्तर के अलावा, यदि आप गेटर के लिए संदर्भ चुनें यह आपके उदाहरण की तरह कुछ भी न लिखें:

YourClass &Member(){ 
    return *this->pMember; 
} 

आपका गेटर वास्तव में, सेटिंग की अनुमति देता है में instance->Member() = YourClass(); और इस तरह अपने सेटर को दरकिनार के रूप में। यदि आपकी क्लास अपरिवर्तनीय है, तो इसकी अनुमति नहीं दी जा सकती है, लेकिन अभी भी एक और बात ध्यान में रखना है। एक और कमी यह है कि गेटर नहीं है।

const YourClass &Member() const { 
    return *this->pMember; 
}