निजी सदस्यों तक पहुंच

Question

क्या यह एक वर्ग के निजी सदस्यों को एक शून्य सूचक और फिर एक संरचना में कास्टिंग करके उचित है?

मुझे नहीं लगता कि मुझे कक्षा में संशोधन करने की अनुमति है जिसमें डेटा सदस्यों को शामिल करने की आवश्यकता है। अगर मैं नैतिक नहीं हूं तो मैं अप्रत्यक्ष तरीके से डेटा सदस्यों तक पहुंचने का जोखिम नहीं लेना चाहता हूं।

संपादित करें: इसे और संपादित करना था ... मुझे पूरा यकीन है कि कक्षा संशोधित नहीं की जाएगी, इसलिए यह उस हद तक ठीक है ... मेरी एकमात्र चिंता यह है कि अगर उस वर्ग को कोड करने वाले व्यक्ति को पता चल जाता है इस के कारण, यह उसके साथ :(अच्छी तरह से नीचे जाना हो सकता है नहीं

Answer 1

"कभी नहीं कहें"। मुझे यकीन है कि ब्रह्मांड में कहीं भी, ऐसी स्थिति है जो आपको यह करने के लिए मजबूर करेगी ...

लेकिन अगर मुझे ऐसा करना पड़े तो मैं निश्चित रूप से क्रिंग करूँगा। ट्रिगर खींचने से पहले आपको वास्तव में अपनी स्थिति पर बहुत सारी राय मिलनी चाहिए। क्या आप अपनी विशिष्ट स्थिति का वर्णन कर सकते हैं और शायद हम देख सकते हैं कि यह समझ में आता है या बेहतर विकल्प क्या हो सकते हैं?

टिप्पणी/प्रश्न के जवाब में - "अनुमतियां" परिभाषित करें - संस्थागत अनुमति? यह प्रोग्रामिंग समस्या की तरह नहीं लगता है, लेकिन जो कुछ भी जोर दे रहा है उससे बात करने के लिए कुछ कहा अनुमति है। शायद यह तकनीकी एक से अधिक राजनीतिक मुद्दा है? दोबारा, मुझे लगता है कि हमें अधिक विशिष्टताओं की आवश्यकता है - भले ही यह स्थिति की राजनीति के बारे में कुछ हद तक हो। हालांकि, वेबसाइट के दायरे से बाहर या नहीं समझा जा सकता है।

Answer 2

मुझे यकीन है कि "नैतिकता" वास्तव में इसे में आने नहीं कर रहा हूँ हालांकि यह कैप्सूलीकरण से बाहर बिल्ली विफल होता है

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

Answer 3

यह नैतिक है, लेकिन यह आमतौर पर अपरिभाषित व्यवहार और अस्पष्टता के साथ पड़ोस के बहुत सारे गंदे कोड पड़ता है। इसे केवल तभी करें जब आपको बिल्कुल करना है।

Answer 4

नहीं। आप जो कर रहे हैं वह शुद्ध ईविल है।

Answer 5

आप ऐसा करने से आग्रह करता हूं महसूस करते हैं, कास्टिंग भूल - बस हेडर फाइल में कक्षा घोषणा संशोधित:

class A { 
    private: 
    int x; 
}; 

परिवर्तन करने के लिए है कि:

class A { 
    public: 
    int x; 
}; 

और आप अच्छे हैं जाने के लिए । खैर, शायद "अच्छा" बिल्कुल सही शब्द नहीं है।

Answer 6

आह, अमूर्त - आप इसे बिना नहीं रह सकता और अभी तक यह कभी कभी :)

वैसे भी

, नैतिकता अलग रूप में, क्या हुआ अगर वर्ग के "मालिक" आंतरिक परिवर्तित करने का निर्णय से निपटने के लिए इतना दर्दनाक है कार्यान्वयन, या बस निजी डेटा सदस्यों के आदेश को उलट देता है?

Answer 7

सरल जवाब: नहीं

यह नैतिक नहीं है और यह कुछ बिंदु पर एक रखरखाव दुःस्वप्न में बदल जाएगा। पुस्तकालय के आंतरिक निजी सदस्य बदल सकते हैं और अपना कोड तोड़ सकते हैं।लाइब्रेरी के डेवलपर्स को यह जानने की आवश्यकता नहीं है कि न ही आप इनकैपलेशन का उल्लंघन कर रहे हैं।

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

यदि विशेषता निजी है, तो यह आपके लिए इसका उपयोग नहीं करना है, केवल कक्षा के लिए या वर्ग के दोस्तों के बारे में जो सदस्य के बारे में जानते हैं, इसका उपयोग कैसे करें, इसे कैसे तोड़ना नहीं है। यदि प्रोग्रामर चाहता था कि आप क्षेत्र को बदलना चाहते हैं, तो यह सार्वजनिक होगा।

Answer 8

चलिए एक पल के लिए नैतिकता पर विचार नहीं करते हैं। आइए मानकों पर विचार करें।

तुम क्या करने का प्रस्ताव कर रहे हैं क्या गैरमानक है। मानक 9 खंड, मानक के खंड 12 देखें। "पहुंच-विनिर्देशक द्वारा अलग किए गए गैर-कानूनी सदस्यों के आवंटन का आदेश अनिर्दिष्ट है।" इसलिए, यदि आपके पास निजी सदस्यों के साथ एक वर्ग है, और कोई निजी सदस्य नहीं है, तो मानक गारंटी नहीं देता है कि सदस्य एक ही क्रम में होंगे।

इसलिए, अपने हैक काम करता है, यह केवल दुर्घटना से काम करता है, कि संकलक लेखकों इसे उस तरह से करने के लिए हुआ है। इस बात की कोई गारंटी नहीं है कि यह एक और कंपाइलर, एक ही कंपाइलर के बाद के संस्करण, या विभिन्न वर्ग लेआउट के साथ काम करेगा।

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

हर्ब Sutter इस मुद्दे पर a Guru of the Week कॉलम लिखा।

ओह, जहाँ तक नैतिकता के रूप में जाना? यदि आप वास्तव में, वास्तव में ऐसा कुछ करना है, और आप इससे बाहर नहीं निकल सकते हैं, तो इसे बहुत सावधानी से दस्तावेज करें। यदि आपके कोडिंग मानकों में गैर-मानक व्यवहार को ध्वजांकित करने के लिए कुछ प्रकार की प्रक्रिया है, तो उनका उपयोग करें। यदि नहीं, तो इसे ध्यान में रखने के लिए बहुत सावधान रहें, जब कुछ गलत हो जाता है तो इसे अनदेखा नहीं किया जाएगा।

Answer 9

मेरे साथ ऐसा हुआ है क्योंकि वहां बहुत क्रोधित स्रोत नियंत्रण प्रणाली थी जहां आवेदन के पुराने संस्करण हेडर फ़ाइलों में परिवर्तन करने के लिए काफी असंभव था।

कुछ मामलों तुम सिर्फ एक हैक करने के लिए की जरूरत है।

स्रोत फ़ाइल जिसमें से आप आप एक पहली पंक्ति के रूप में इस में डाल सकते हैं निजी डेटा सदस्य का उपयोग करने की जरूरत है में:

#define private public 
#define protected public 

और कुछ भी आप चाहते हैं का उपयोग।

Answer 10

एकमात्र "नैतिक" समस्या यह है कि आप गरीब बेस्टर्ड को क्या कर रहे हैं जो आपके कोड को समझने और बनाए रखने के लिए जा रहा है।

निजी सदस्य बस यही हैं। वह, और सबसे अधिक संभावना है, एक दिन उस सदस्य को बदल सकता है। जब ऐसा होता है, तो हो सकता है कि आप यह भी ध्यान न दें कि वहां संभवतः वहां मौजूद स्मृति होगी, केवल उस सदस्य को नहीं जिसे आप उम्मीद कर रहे थे। जब आप अपना कोड चलाते हैं तो किसी भी लगभग असंभव चीज के बारे में आप कल्पना कर सकते हैं तो हो सकता है। कोई भी कभी डीबग करने में सक्षम होने वाला कैसे है?

Answer 11

मैं सिर्फ एक entry to my blog से पता चलता है कि यह कैसे एक पूरी तरह से अनुरूप तरीके से किया जा सकता है जोड़ दिया है। यहाँ कैसे आप इसे निम्नलिखित वर्ग

struct A { 
private: 
    int member; 
}; 

के लिए उपयोग बस एक टैग नाम घोषित करने और निम्न उदाहरण से पता चलता है की तरह एक डाकू का दृष्टांत पर एक उदाहरण है (मेरी पोस्ट डाकू के कार्यान्वयन से पता चलता)। इसके बाद आप एक सदस्य सूचक

struct Amem { typedef int type; }; 
template class rob<Amem, &A::member>; 

int main() { 
    A a; 
    a.*result<Amem>::ptr = 42; // Doh! 
} 

का उपयोग कर कि सदस्य का उपयोग कर सकते लेकिन वास्तव में, यह प्रदर्शित नहीं करता है कि C++ का एक्सेस नियम विश्वसनीय नहीं हैं। भाषा नियमों को आकस्मिक गलतियों से बचाने के लिए डिज़ाइन किया गया है - यदि आप किसी ऑब्जेक्ट के डेटा को लूटने का प्रयास करते हैं, तो द्वारा डिज़ाइन द्वारा आपको रोकने के लिए लंबा रास्ता नहीं लगता है।

---

ऊपर एक अनुरूप रास्ते में निजी और संरक्षित सदस्यों तक पहुँचने के लिए एक तरीका है। सुरक्षित मानक अनुरूप तरीके से सदस्यों तक पहुंचने का यह एक और तरीका है। मूल विचार एक सदस्य सूचक

std::deque<int> &getAdapted(std::stack<int> &s) { 
    struct voyeur : stack<int> 
    { using stack<int>::c; }; 
    return s.*(&voyeur::c); 
} 

int main() { 
    std::stack<int> s; 
    std::deque<int> &adapted = getAdapted(s); 
    output(adapted); // print the stack... 
} 

कोई कास्टिंग या प्रकार पनिंग शामिल नहीं है। यह std::stack<int> के संरक्षित सदस्य को उस से प्राप्त कक्षा के माध्यम से एक सूचक लेता है जहां उस सदस्य का नाम सार्वजनिक है, इसलिए संकलक इसे अनुमति देता है। फिर यह std::stack<int> ऑब्जेक्ट पर इसका उपयोग करता है, जिसे भी अनुमति है।

Answer 12

मुझे लगता है कि इस वर्ग के परियोजना आप पर काम कर रहे का हिस्सा है।

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

हैक आप उल्लेख है कि वास्तव में अभ्यास बिस्तर है। अगर उस कोड को संशोधित नहीं कर सकता है और रखरखाव कुछ भी बदलने के लिए नहीं है। एडाप्टर डिजाइन पैटर्न का उपयोग करने पर विचार करें।