क्या हमें वास्तव में एक सुरक्षित रिलीज मैक्रो की आवश्यकता है?

Question

काफी बहुत से लोगों को एक मैक्रो जैसे

#define SAFE_RELEASE(X) [X release]; X = nil; 

(अपने आप को शामिल) उपयोग करने के लिए लग रहे हैं।

मैं पुन: मूल्यांकन कर रहा हूं कि मैं इसका उपयोग क्यों कर रहा हूं और कुछ राय कैनवास करना चाहता हूं।

उद्देश्य (मुझे लगता है कि) इस मैक्रो का उपयोग के लिए है, इसलिए है कि अगर आप के लिए गए थे गलती से इसे जारी करने के बाद अपने ऑब्जेक्ट का उपयोग तो आप क्योंकि उद्देश्य-सी काफी खुशी से इसे अनदेखा जाएगा जब एक बुरा पहुँच अपवाद नहीं मिलेगा वस्तु शून्य है।

यह मुझे मारता है कि इसमें कुछ अस्पष्ट बग मास्क करने की क्षमता है। जब आप एक्स का फिर से उपयोग करने का प्रयास करते हैं तो शायद यह प्रोग्राम को क्रैश होने के लिए बेहतर होगा। इस तरह परीक्षण के दौरान आप समस्या पा सकते हैं और कोड में सुधार कर सकते हैं।

क्या यह मैक्रो आलसी प्रोग्रामिंग को प्रोत्साहित करता है?

विचार?

Answer 1

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

हालांकि, एक समझौता है कि मैं समय-समय पर देखा है:

• यह दुर्घटना विकास के दौरान बनाओ
• उत्पादन कोड में var = nil; करो

इस तरह यह पराक्रम ग्राहकों के भुगतान के साथ और अधिक विश्वसनीय हो और विकास के दौरान जल्दी ही दुर्घटनाग्रस्त हो।

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

Answer 2

आप की आवश्यकता नहीं है, लेकिन यह आसान है। मैं अपने ऐप्स में कुछ समान उपयोग करता हूं। आप इसे "आलसी" मान सकते हैं, लेकिन जब आपके पास लगभग 20 ऑब्जेक्ट्स हैं, तो इन्हें लिखकर मैन्युअल रूप से थकाऊ हो जाता है।

Answer 3

मुझे लगता है कि यह, या लागू होने पर self.myVar = nil जैसे समकक्ष, अच्छा है। ऐसे कई मामले हैं जहां आप बस नील असाइन नहीं कर सकते हैं और बाद में पहुंच किसी भी बग को मान सकते हैं।

उदाहरण के लिए यूआईकिट में ओएस पूछने पर जितना संभव हो उतना संसाधन मुक्त करने का अच्छा व्यवहार है। जैसे

- (void)didReceiveMemoryWarning 
{ 
    [myCachedData release]; 
    [super didReceiveMemoryWarning]; 
} 

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

Answer 4

मैं एक ही प्रश्न में देख रहा था।पढ़ने के थोड़ा सा मैंने मेरे पास ऐसा कुछ किया:

#define DEBUGGING 
    //#define PRODUCTION 

#ifdef DEBUGGING 
#define SAFE_RELEASE(X) [X release]; 
#else 
#define SAFE_RELEASE(X) [X release]; X = nil; 
#endif 

तो अगर मैं विकास कर रहा हूं तो मुझे क्रैश मिलते हैं। उत्पादन में मैं नहीं करता हूं।

स्कॉट < -

Answer 5

के रूप में एंड्रयू ने कहा, ऐसे मामले हैं जहां nil केवल कीड़े से परहेज नहीं है, लेकिन आवश्यक बताए हैं। बस ठेठ पर विचार UIViewController कोड

- (void)viewDidLoad { 
    button = [UIButton buttonWithType:UIButtonTypeRoundedRect]; // autoreleased 
    [button retain]; // keep alive 
} 

- (void)viewDidUnload { // view has been removed 
    [button release]; 
} 

- (void)dealloc {  // destroying the view controller 
    [button release]; // <-- problem 
} 

मामले में नियंत्रक लोड किया जाता है, बाद में उतार दिया (क्योंकि अन्य दृश्य नियंत्रक एक स्मृति कम चल रहा है प्रदर्शित किया जाता है) और अंत में नष्ट कर दिया, [button release]dealloc में ओवर-द रिलीज होगी बटन (भेजना एक जारी वस्तु को एक संदेश)। इसलिए यह शून्य नियुक्त करना आवश्यक है। सुरक्षित समाधान होगा:

- (void)viewDidUnload { // view has been removed 
    [button release]; 
    button = nil; 
} 

- (void)dealloc {  // destroying the view controller 
    [button release]; // <-- safe 
} 

उन मामलों के लिए एक मैक्रो अच्छा और उपयोगी है। के बारे में यह क्या करता है, उतना ही अच्छा

#define RELEASE_AND_NIL(X) [X release]; X = nil;