सी ++: निजी कार्यों को क्यों घोषित किया जाना चाहिए?

Question

सी ++ में कक्षाओं को अपने निजी कार्यों की घोषणा क्यों करनी है? क्या यह वास्तविक तकनीकी कारण है (संकलन समय में इसकी भूमिका क्या है) या यह केवल स्थिरता के लिए है?

Answer 1

मैं, पूछा क्यों निजी कार्यों के सभी पर घोषित किया जाना था वे अन्य अनुवाद इकाइयों के लिए कुछ भी (न तो वस्तु के आकार और न ही vtable प्रविष्टि) पता करने के लिए

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

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

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

एक अंतिम नोट यह है कि, private फ़ंक्शंस vtable आकार को प्रभावित कर सकता है। यही है, अगर वे virtual हैं।

---

_{वास्तव में पूरी तरह से नहीं। यदि आपके पास कक्षा में इनलाइन फ़ंक्शन हैं, तो वे बाद में उसी कक्षा में परिभाषित कार्यों का उल्लेख कर सकते हैं। लेकिन शायद विचार एकल पास से शुरू हुआ और बाद में इस अपवाद को इसमें जोड़ा गया।}

_{यह विशेष रूप से इनलाइन सदस्य कार्य है।}

Answer 2

पहुंच स्तर दृश्यता को प्रभावित नहीं करता है। निजी कार्यों बाहरी कोड के लिए दिखाई दे रहे हैं और अधिभार संकल्प (जो तब एक पहुँच violoation त्रुटि में परिणाम होगा) द्वारा चुना जा सकता है:

class A { 
    void F(int i) {} 
public: 
    void F(unsigned i) {} 
}; 

int main() { 
    A a; 
    a.F(1); // error, void A::F(int) is private 
} 

भ्रम की कल्पना करें जब यह काम करता है:

class A { 
public: 
    void F(unsigned i) {} 
}; 

int main() { 
    A a; 
    a.F(1); 
} 

// add private F overload to A 
void A::F(int i) {} 

लेकिन यह बदल रहा है पहले कोड में एक अलग फ़ंक्शन का चयन करने के लिए ओवरलोड रिज़ॉल्यूशन का कारण बनता है। और निम्नलिखित उदाहरण के बारे में क्या?

class A { 
public: 
    void F(unsigned i) {} 
}; 

// add private F overload to A 
void A::F(int i) {} 

int main() { 
    A a; 
    a.F(1); 
} 

या यहाँ इस का एक और उदाहरण गलत हो रहा है:

// A.h 
class A { 
public: 
    void g() { f(1); } 
    void f(unsigned); 
}; 

// A_private_interface.h 
class A; 
void A::f(int); 

// A.cpp 
#include "A_private_interface.h" 
#include "A.h" 

void A::f(int) {} 
void A::f(unsigned) {} 

// main.cpp 
#include "A.h" 

int main() { 
    A().g(); 
} 

Answer 3

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

यदि आपके पास कोई तरीका है जो केवल .cpp फ़ाइल में उपयोग किया जाता है और कक्षा के अन्य निजी सदस्यों तक सीधे पहुंच पर निर्भर नहीं करता है, तो उसे अज्ञात नेमस्पेस पर ले जाने पर विचार करें। फिर, इसे हेडर फ़ाइल में घोषित करने की आवश्यकता नहीं है।

Answer 4

आपको कक्षा के परिभाषा में सभी सदस्यों को घोषित करना होगा ताकि संकलक जानता हो कि सदस्यों के लिए कौन से फ़ंक्शन हैं। अन्यथा, एक दूसरा प्रोग्रामर (गलती से?) साथ आ सकता है और सदस्यों को जोड़ सकता है, गलतियां कर सकता है, और अपनी वस्तु की गारंटी का उल्लंघन कर सकता है, जिससे अपरिभाषित व्यवहार और/या यादृच्छिक दुर्घटनाएं हो सकती हैं।

Answer 5

निजी कारणों को घोषित क्यों किया जाना चाहिए इसके कुछ कारण हैं।

पहले संकलन समय त्रुटि जाँच

पहुँच संशोधक के बिंदु संकलन समय पर प्रोग्रामिंग त्रुटियों के कुछ वर्गों (कोई यमक इरादा) को पकड़ने के लिए है। निजी कार्य कार्य होते हैं, यदि किसी ने उन्हें कक्षा के बाहर से बुलाया है, तो यह एक बग होगा, और आप जितनी जल्दी हो सके इसके बारे में जानना चाहते हैं।

दूसरा कास्टिंग और विरासत

सी ++ मानक से लिया:

3 [ध्यान दें: एक निजी आधार वर्ग के एक सदस्य सीधे एक विरासत सदस्य नाम के रूप में दुर्गम है, लेकिन सुलभ हो सकता है। पॉइंटर रूपांतरण (4.10) और स्पष्ट कास्ट (5.4) के नियमों के कारण, एक सूचक से एक व्युत्पन्न कक्षा में एक पॉइंटर से एक अपरिवर्तनीय बेस क्लास में एक रूपांतरण हो सकता है यदि एक अंतर्निहित रूपांतरण का उपयोग किया जाता है, लेकिन अच्छी तरह से गठित किया गया है अगर एक स्पष्ट कास्ट का उपयोग किया जाता है।

3 दोस्त

मित्रों को एक दूसरे वहाँ साधारण सैनिक दिखा। एक निजी विधि को किसी अन्य वर्ग द्वारा कॉल किया जा सकता है जो एक दोस्त है।

4 जनरल विवेक और अच्छा डिजाइन

कभी एक और 100 डेवलपर्स के साथ एक परियोजना पर काम किया। एक मानक और नियम का एक सामान्य सेट रखने के लिए बनाए रखने में मदद करता है। कुछ निजी घोषित करने से समूह में हर किसी के लिए एक विशिष्ट अर्थ होता है।

यह भी अच्छा ओओ डिजाइन सिद्धांतों में बहता है। क्या पर्दाफाश करने के लिए और क्या नहीं

Answer 6

चिंताओं का एक संयोजन नहीं है, लेकिन:

• सी ++ आप फिर से खुल एक वर्ग अपनी प्रारंभिक परिभाषा के बाद उस में नए सदस्यों की घोषणा करने नहीं देता।
• सी ++ आपको विभिन्न अनुवाद इकाइयों में एक वर्ग की अलग-अलग परिभाषाएं नहीं देता है जो प्रोग्राम बनाने के लिए गठबंधन करते हैं।

इसलिए:

• किसी भी निजी सदस्य कार्यों कि .cpp फ़ाइल वर्ग में घोषित चाहता है ज फ़ाइल है, जो वर्ग के हर उपयोगकर्ता भी देखता है के रूप में परिभाषित किया जाना चाहिए।

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

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

शायद दोनों के लिए हाँ। मुझे नहीं लगता कि कोई तकनीकी बाधा है, हालांकि वर्तमान ओडीआर बहुत परिभाषा "अलग" परिभाषा के बारे में सख्त है (और इसलिए बहुत ही दिखने वाली परिभाषाओं के बीच बाइनरी असंगतताओं को अनुमति देने में कार्यान्वयन के लिए बहुत उदार है)। मुझे लगता है कि इस तरह के अपवाद को लागू करने के लिए पाठ जटिल होगा।

आखिरकार यह नीचे आ सकता है, "डिजाइनर इसे इस तरह से चाहते थे", या ऐसा हो सकता है कि किसी ने इसे आजमाया और उस बाधा का सामना किया जिसे मैंने नहीं सोचा था।

Answer 7

एक कारण यह है कि सी ++ दोस्तों में आपके निजी लोगों तक पहुंच सकते हैं। दोस्तों के लिए उन्हें एक्सेस करने के लिए, दोस्तों को उनके बारे में पता होना चाहिए।