2012-08-07 9 views
5

ऑब्जेक्टिव-सी की विरासत संस्करण में, एक objc_class struct इस तरह कार्यान्वित किया जाता है:ऑब्जेक्टिव-सी 2.0 ऑब्जेक्ट में संग्रहीत इंस्टेंस चर और विधियां कैसे हैं?

struct objc_class { 
    Class isa; 
    Class super_class; 
    const char *name; 
    long version; 
    long info; 
    long instance_size; 
    struct objc_ivar_list *ivars; 
    struct objc_method_list **methodLists; 
    struct objc_cache *cache; 
    struct objc_protocol_list *protocols; 
}; 

तो, struct है कि एक वस्तु का प्रतिनिधित्व करता है वस्तु के वर्ग के लिए एक सूचक, वस्तु के सुपर वर्ग के लिए एक सूचक को संग्रहीत करता है , ऑब्जेक्ट का क्लास नाम, ऑब्जेक्ट का संस्करण, जानकारी और इंस्टेंस आकार, ऑब्जेक्ट की आवृत्ति चर सूची, ऑब्जेक्ट की विधियों की सूची, ऑब्जेक्ट का कैश और ऑब्जेक्ट की प्रोटोकॉल सूची। किसी ऑब्जेक्ट का प्रतिनिधित्व करने वाली संरचना में इन फ़ील्ड की उपस्थिति काफी समझ में आता है क्योंकि उनमें से प्रत्येक वस्तु के बारे में जानकारी संग्रहीत करता है।

हालांकि, एक ही struct objc_class की ऑब्जेक्टिव-सी 2.0 कार्यान्वयन इस तरह है:

struct objc_class { 
    Class isa; 
}; 

तो, objc_class के इस संस्करण में, वहाँ struct में केवल एक ही क्षेत्र है: ऑब्जेक्ट के लिए सूचक वर्ग संरचना।

मेरा प्रश्न, तो, उद्देश्य-सी 2.0 में संग्रहीत ऑब्जेक्ट के बारे में अन्य जानकारी कैसी है क्योंकि ऑब्जेक्ट्स का प्रतिनिधित्व करने वाली संरचना में केवल एक फ़ील्ड है?

+3

दिलचस्प पढ़ना: [\ [objc व्याख्या \]: गैर-नाजुक ivars] (http://www.sealiesoftware.com/blog/archive/2009/01/27/objc_explain_Non-fragile_ivars.html) –

उत्तर

7

यह सब नया है (ठीक है, अब इतना नया नहीं है) गैर-नाजुक एबीआई।

असल में, बजाय एक struct के अंदर Ivars भंडारण की तरह आप के लिए इस्तेमाल किया (जो विरासत टूट जाएगा अगर एक सुपर क्लास बदल यह इवर लेआउट है) की, संकलक इवर पुनर्निर्देशन एक और परत, कार्यावधि में objc_setAssociatedObject के लिए इसी तरह के माध्यम से डालता है।

यह कुछ दिलचस्प परिदृश्यों के लिए अनुमति देता है। पर विचार करें निम्नलिखित:

@interface A { // part of libA.a 
    id var1; 
    int var2; 
    float var3; 
} 

@end 

@interface B : A { // part of libB.a 
    id var4; 
} 

@end 

अब, क्या हुआ अगर कुछ समय सड़क के नीचे, हम वर्ग A बदलने की जरूरत है और हम निर्धारित हम var3 में और अधिक सटीक की जरूरत है (एक long double करने के लिए इसे परिवर्तित करने, उदाहरण के लिए)?

पुराने, नाजुक एबीआई में, हम libB के निर्माता तक अद्यतन हो जाएंगे। हालांकि, इस नए, गैर-नाजुक एबीआई के साथ, हमारे पास यह सब बदलने के लिए flexibilty है जबकि libB अभी भी काम करता है।

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

+0

ठीक है। तो, उद्देश्य-सी के "नए" संस्करण में, संकलन-समय में संरचना को भरने के बजाय, ऑब्जेक्ट ivars और methodos को 'class_addIvar' और' class_addMethod' जैसे कार्यों द्वारा रन-टाइम में संग्रहीत किया जाता है? सभी इरादों और उद्देश्यों के लिए – LuisABOL

+0

@ लैबोलिट, हाँ, वे हैं। वास्तविकता में, वे अभी भी एक संरचना के रूप में संग्रहीत हैं, लेकिन उनकी ऑफसेट अलग-अलग है। –

+0

लेकिन ये structs रनटाइम सिस्टम से संबंधित हैं और ऊपर वर्णित कार्यों से भरे हुए हैं, है ना? – LuisABOL

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