जब मैं एआरसी के बारे में सोचता हूं तो रिलीज का कोई ओवरहेड नहीं होता है। लेकिन एक बार Core Foundation चर में आते हैं, उन्हें एआरसी में भी रिलीज़ होने की आवश्यकता होती है।उद्देश्य-सी: क्यों कोर फाउंडेशन चर को एआरसी में स्पष्ट रिलीज की आवश्यकता है?
हालांकि एआरसी नियम NS.. और CF.. दोनों के लिए अलग हैं, फिर भी एआरसी में CF.. का समर्थन नहीं करने के लिए कोई विशिष्ट कारण है?
जब मैं एआरसी के बारे में सोचता हूं तो रिलीज का कोई ओवरहेड नहीं होता है।
मुझे लगता है कि "मुझे रिलीज के बारे में चिंता करने की ज़रूरत नहीं है।" अक्सर कुछ प्रदर्शन ओवरहेड होता है, हालांकि संकलक कभी-कभी इसे अनुकूलित कर सकता है।
हालांकि एआरसी नियम एनएस दोनों के लिए अलग हैं .. और सीएफ .. क्या एआरसी में सीएफ का समर्थन नहीं करने के लिए कोई विशिष्ट कारण है?
कई कोर फाउंडेशन वस्तुओं एआरसी द्वारा प्रबंधित कर रहे हैं, और उनमें से संख्या बढ़ रही रखता है। आप बता सकते हैं कि CF_IMPLICIT_BRIDGING_ENABLED के लिए हेडर में देखकर कोई विशेष फ़ंक्शन एआरसी का समर्थन करता है या नहीं। यदि आप इसे देखते हैं, तो फ़ंक्शन एआरसी-संगत सीएफ ऑब्जेक्ट्स लौटाते हैं। उदाहरण के लिए, आईओएस 8 में, सूची में कई कोर ग्राफिक्स फ़ंक्शंस जोड़े गए थे। (मैं इसे ओवरस्टेट नहीं करना चाहता; मैं यह नहीं कह रहा हूं कि आज आप CFRelease इन पर नहीं हैं। मैं कह रहा हूं कि वे एआरसी द्वारा प्रबंधित किए जाने के लिए सेटअप हैं, वे स्विफ्ट में एआरसी द्वारा प्रबंधित हैं, और वे हो सकता है अंततःCFRelease की जरूरत के बिना ObjC में सीधे नियंत्रित किया।)
कारण सीएफ वस्तुओं डिफ़ॉल्ट द्वारा प्रबंधित नहीं कर रहे हैं है कि किसी के माध्यम से जाना होगा और सत्यापित (ऑडिट करने के लिए) है कि हर समारोह बनाएं के अनुरूप था नियम नामकरण सम्मेलन या वे अपने अपवादों के लिए सही ढंग से एनोटेटेड हैं। यह काफी कठिन काम है, और ऐप्पल ने कई रिलीज में इसे फैलाया है। लेकिन आपको यह समय के साथ बेहतर और बेहतर होना चाहिए।
काज़ुकी सही है कि आप एआरसी-प्रबंधित वस्तुओं को संरचना या संघ में नहीं डाल सकते हैं, लेकिन यह आमतौर पर कोर फाउंडेशन को प्रभावित नहीं करता है।
बीटीडब्ल्यू, CF_IMPLICIT_BRIDGING_ENABLEDarc_cf_code_audited क्लैंग प्रगा के आसपास सिर्फ एक रैपर है। यह एआरसी दस्तावेज़ों, 7.8.1 Auditing of C retainable pointer interfaces में समझाया गया है।
कोर फाउंडेशन a pure C library है। इस प्रकार, कम से कम, एक कारण है कि एआरसी सीधे कोर फाउंडेशन ऑब्जेक्ट का समर्थन नहीं कर सकता है। structs की
4.3.5 स्वामित्व योग्य खेतों और यूनियनों
एक कार्यक्रम बीमार बनाई है अगर यह एक सी struct या यूनियन का सदस्य घोषित किया है करने के लिए एक nontrivially स्वामित्व योग्य प्रकार।
दलील
जिसके परिणामस्वरूप के प्रकार सी ++ अर्थ में गैर पॉड होगा, लेकिन सी समुच्चय के जीवन भर के प्रबंधन के लिए हमें बहुत अच्छा भाषा उपकरण नहीं देता है, तो इसे और अधिक सुविधाजनक है बस उन्हें मना करने के लिए । यह अभी भी संभव है इसे शून्य * या __unsafe_unretained ऑब्जेक्ट के साथ प्रबंधित करें।
तो LLVM संकलक structs और यूनियनों के साथ-साथ इस व्याख्या में कोर फाउंडेशन वस्तुओं के जीवन, C does not give us very good language tools for managing the lifetime of aggregates की वजह से संभाल सकते हैं।
मुझे पता है क्यों नहीं लेकिन क्यों ** ** अगर यह समझ में आता है। सीएफ आईओएस और ओएस एक्स के लिए उपलब्ध सी सी फ्रेमवर्क है और एआरसी कंपाइलर इसमें स्मृति आवंटन को ट्रैक नहीं कर सकता है। यही कारण है कि आपको सामान को मैन्युअल रूप से रिलीज़ करने की आवश्यकता है। लेकिन मुझे नहीं पता ** क्यों ** एआरसी ट्रैक करने में सक्षम नहीं है। ऐसा कहकर, यह इस कारण का हिस्सा है कि स्विफ्ट साथ आया था। यह सी सामान की पूरी तरह से आवश्यकता को हटा देता है। :) – Fogmeister
@Fogmeister: सहमत हैं, लेकिन सीएफ आयात नहीं है क्योंकि यह सी से है? यदि नहीं, तो आवश्यकता को पूरा करने के लिए संशोधित क्यों नहीं किया गया है? – preetam