16

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

मैंने सोचा था कि मैं समझ गया जब तक मैं पूछा गया था कि क्या स्वामित्व (weak, strong, assign, आदि) के प्रकार के एक केवल पढ़ने के लिए संपत्ति किसी ऑब्जेक्ट पर इंगित करने के लिए दी जानी चाहिए, जैसे:

@property (readonly,nonatomic) NSString* name; 

मैं यहाँ पढ़ Questions about a readonly @property in ARCstrong/weak को छोड़कर वास्तव में संकलित नहीं होगा जब तक आप @synthesize संपत्ति को बैकिंग चर निर्दिष्ट नहीं करते हैं;

@synthesize name = _name; 

अब मैं, समझ में यहां से कि एक चर के डिफ़ॉल्ट 'जीवन क्वालीफायर' मजबूत है: http://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4

तो एक लम्बी कहानी में कटौती करने के मैं सिर्फ इसलिए इस तरह एक समर्थन इवर को निर्दिष्ट किया हुआ संक्षेप में - मैं (readonly,nonatomic,strong) के रूप में अप्रत्यक्ष रूप से अपनी संपत्ति को परिभाषित कर रहा हूं क्योंकि _name ivar को __strong के रूप में घोषित किया गया है।

  1. strong उपयोग करने के लिए सही जीवन क्वालीफायर है:

    मैं कुछ प्रश्न हैं? मुझे लगता है कि यह है, अन्यथा मेरे NSString* का समर्थन करने वाली वस्तु का स्वामित्व कहीं भी नहीं होगा और इस प्रकार स्वचालित रूप से मुक्त हो जाएगा (जावा भूमि से आने से यह समझ में आता है क्योंकि सभी संदर्भ डिफ़ॉल्ट रूप से मजबूत होते हैं)।

  2. क्या कोई अन्य संशोधक है जो इस स्थिति में copy या assign जैसी समझ में आता है?

  3. (readonly,nonatomic,strong) और (readonly,nonatomic) के रूप में संपत्ति की घोषणा करता है कोड है जो खपत संपत्ति को कोई फर्क? जैसे। strong कीवर्ड के बिना इसे घोषित करता है ऑब्जेक्ट पॉइंटर __unsafe_unretained के रूप में संग्रहीत किया जाता है जहां strong संपत्ति __strong सूचक में संग्रहीत की जाएगी?

धन्यवाद!

संपादित

तो जैसा कि अब मैं समझ, निम्नलिखित गुण केवल पढ़ने के लिए लागू होता है:

  • गैर NSObject के लिए * प्रकार (int, नाव, शून्य *, आदि) (readonly, assign) का उपयोग करें।
  • ऑब्जेक्ट पॉइंटर्स के लिए, (readonly, strong) या (readonly, copy) का उपयोग करें - ये कार्य केवल पढ़ने योग्य गुणों के लिए समान हैं लेकिन यदि आप विस्तार/उपclass और readwrite के रूप में संपत्ति को पुन: प्राप्त करते हैं तो आप कॉपी सेमेन्टिक्स चाहते हैं।
  • ऑब्जेक्ट पॉइंटर्स के लिए, (readonly, weak) केवल तभी समझ में आता है जब आप उस संपत्ति में पहले से ही कमजोर सूचक को संग्रहीत करने जा रहे हैं (वह पॉइंटर कहीं और मजबूत होना चाहिए या ऑब्जेक्ट को हटा दिया जाएगा)।
+0

ध्यान दें कि "मजबूत" निहित है, इसलिए यदि आप का विस्तार '(मजबूत) 'के साथ एक पठनीय रूप से निर्दिष्ट' (केवल पढ़ने वाला) 'यह काम करेगा, लेकिन' (प्रतिलिपि)' नहीं होगा। इसके बजाय आप देखेंगे "एआरसी एक संपत्ति को संश्लेषित करने से मना करता है ... अनिर्दिष्ट स्वामित्व या भंडारण विशेषता के साथ।" इस मामले में आपको हेडर परिभाषा '(रीडराइट, कॉपी)' में स्पष्ट होना चाहिए। यह मुझे कुछ मिनट के लिए फिसल गया। –

उत्तर

12
  1. strong आप जो कुछ भी करने के लिए यह है कि आप ओर इशारा करते हैं एक मजबूत (मालिक) संदर्भ रखना चाहते हैं का उपयोग करने के लिए सही है। आम तौर पर, आप मजबूत चाहते हैं, लेकिन परिपत्र संदर्भों को रोकने के लिए (विशेष रूप से माता-पिता/बाल संबंधों में जहां माता-पिता बच्चे को इंगित करते हैं और बच्चे माता-पिता को इंगित करते हैं, उन्हें कभी भी जारी नहीं किया जाएगा) आपको कभी-कभी कमजोर संदर्भों का उपयोग करने की आवश्यकता होती है । साथ ही, यदि आप उस ऑब्जेक्ट पर पॉइंटर रखना चाहते हैं जिसका आपके पास स्वामित्व नहीं है, लेकिन यह मान्य होना चाहिए, जब तक यह मौजूद हो, तो आप एक कमजोर सूचक का उपयोग करना चाहते हैं क्योंकि जब यह मालिक द्वारा अस्वीकृत हो जाता है, आपका पॉइंटर स्वचालित रूप से nil पर सेट हो जाएगा और यह स्मृति को इंगित नहीं करेगा कि यह नहीं होना चाहिए।

  2. assign स्केलर मानों के साथ प्रयोग किया जाता है, और डिफ़ॉल्ट सेटटर है। copy समझ में आता है यदि आप ऑब्जेक्ट की एक प्रति स्वचालित रूप से बनाना चाहते हैं और मूल ऑब्जेक्ट को इंगित करने के बजाय अपने पॉइंटर को प्रतिलिपि पर सेट करना चाहते हैं। यदि आपके पास एक विशिष्ट आवश्यकता है (आमतौर पर क्योंकि आप नहीं चाहते कि ऑब्जेक्ट आप पर म्यूटेट करना चाहे) तो यह केवल यह समझ में आता है।

  3. लिंक आपके द्वारा प्रदान किया है जो दिखाता है डिफ़ॉल्ट है कि __strong (और इसलिए आप इसे निर्दिष्ट करने की आवश्यकता नहीं है) चर और नहींको घोषित गुण को दर्शाता है। घोषित गुणों के लिए डिफ़ॉल्ट assign है, इसलिए यह निश्चित रूप से एक अंतर बनाएगा। यदि आप assign चाहते थे, तो इससे कोई फर्क नहीं पड़ता कि आप इसे निर्दिष्ट करते हैं या नहीं (केवल यह स्पष्ट करने के अलावा कि यह वही है जो आप चाहते थे)। संपादित: लेकिन, जैसा कि जैक ने कहा, इस LLVM 3.1 के साथ बदल रहा है और डिफ़ॉल्ट strong- बदलते assign से है। इस मामले में, यह बिल्कुल कोई फर्क नहीं पड़ता कि आप strong निर्दिष्ट करते हैं या नहीं, और यदि आप चाहें तो इसे छोड़ सकते हैं। व्यक्तिगत रूप से मुझे लगता है कि इसे वर्तनी करना अच्छा होता है (विशेष रूप से क्योंकि विभिन्न संस्करणों के बीच एक संघर्ष होता है) ताकि कोड को देखकर हर कोई एक ही पृष्ठ पर हो। हालांकि इस बिंदु पर अन्य असहमत हो सकते हैं। :)

मैं के पढ़ने घोषित गुण अनुभाग ऑब्जेक्टिव-सी प्रोग्रामिंग भाषा यहाँ सुझाव है: <document removed by Apple with no direct replacement>

+0

उन्होंने वास्तव में गुणों के लिए डिफ़ॉल्ट भी बदल दिया, क्लैंग की अगली रिलीज (3.1) के रूप में: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling.property –

+0

दिलचस्प ... अब यह एआरसी और गैर-एआरसी कोड के बीच अलग है। धन्यवाद @ जैक्सकौस्टाऊ! – lnafziger

+1

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

7

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

जैसा कि वर्तमान में चीजें खड़ी हैं, संपत्ति के सभी अन्य गुणों को सुसंगत होना चाहिए। यह कल्पना की जा सकती है कि संकलक इस आवश्यकता को आराम कर सकता है। (कुछ इसे एक बग मानते हैं।) वैसे भी, संपत्ति strong, copy, या कमजोर के साथ संपत्ति घोषित करने का एक कारण है - ताकि यह कहीं और readwrite पुनर्विक्रय से मेल खाए।

आपके प्रश्न 3 के संबंध में, क्या आप पूछ रहे हैं कि स्वामित्व क्वालीफायर कोड को प्रभावित करता है जो गेटर को कॉल करता है?नहीं, यह नहीं करता है।

+1

तो मजबूत/कमजोर संशोधक नहीं करता है संश्लेषित ivar के आजीवन क्वालीफायर को बदलने के अलावा अन्य पढ़ने योग्य संपत्ति में कोई फर्क पड़ता है, क्या यह सही है? –

+1

हां, यह सही है। –

+0

आपकी मदद के लिए बहुत बहुत धन्यवाद! –

0

इन 2 मेरे लिए कोड काम की तर्ज:

ज फ़ाइल:

@property (nonatomic, readonly, copy) NSString *username; 

मीटर फ़ाइल:

@property (nonatomic, readwrite, copy) NSString *username; 

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^