2009-04-22 8 views
9

में शीर्षलेख फ़ाइलों को शामिल करने की लागत यह वास्तव में बेवकूफ सवाल की तरह प्रतीत हो सकती है, लेकिन उद्देश्य-सी में एक हेडर फ़ाइल (वास्तव में, #import पर कॉल करने) की लागत क्या है? मैं लगातार विभिन्न स्थानों में एक ही शीर्षलेख सहित थक गया हूं, इसलिए मैंने बस GlobalReferences.h फ़ाइल बनाने का निर्णय लिया जिसमें कई सामान्य-संदर्भित शीर्षलेख शामिल हैं।उद्देश्य-सी

क्या अन्य फ़ाइलों के संदर्भों को शामिल करने के लिए कोई सराहनीय लागत है यदि उनका उपयोग भी नहीं किया जाता है? मेरा आंत मुझे "नहीं" बताता है क्योंकि ऐसा लगता है कि #import का उपयोग करते समय लिंकर को अन्य फाइलों के बारे में पता चला है, लेकिन मुझे यकीन नहीं था कि आईफोन विकास के लिए विशेष विचारों की आवश्यकता है, जो मेरी परियोजना से संबंधित है। कोई विचार?

उत्तर

7

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

कच्चे स्रोत कोड की तरह (सभी हेडर फाइल और विस्तार मैक्रो आदि सहित) लग रहा है क्या देखने के लिए:

gcc -E your-source-file.m 
+0

इसे साफ़ करने के लिए धन्यवाद। – LucasTizma

2

सबसे बड़ी खामी संकलन के दिनों में हो जाएगा। यदि आपके सभी शीर्षलेख प्रत्येक स्रोत फ़ाइल में आयात किए जाते हैं, तो संपूर्ण प्रोजेक्ट को प्रत्येक बार जब आप हेडर फ़ाइल में परिवर्तन करते हैं तो पुनर्निर्मित करना होगा।

3

आयात करने/आपकी आवश्यकता से अधिक हेडर फाइलों को शामिल करने से संकलन के समय में वृद्धि होगी। आप pre-compiled headers के साथ इस दर्द में से कुछ को कम कर सकते हैं। http://en.wikipedia.org/wiki/Objective-C#.23import

1

मैं धारणा है कि यह एक हिट की बहुत अधिक नहीं होगा तहत किया गया। जब तक आप जिन शीर्षकों को शामिल कर रहे हैं वे बड़े पैमाने पर नहीं हैं और आप प्रीकंपील्ड हेडर का उपयोग नहीं कर रहे हैं, तो आपको कोई अंतर नहीं दिखना चाहिए। जैसा कि अन्य ने कहा है, #import एक प्रीप्रोसेसर निर्देश है। इसका कोई रनटाइम परिणाम नहीं है और कई मामलों में कोई महत्वपूर्ण संकलन समय परिणाम नहीं है।

0

आगे बढ़ो और यह कार्य करें:

+0

इस मुद्दे के बारे में आपकी स्पष्टीकरण के लिए, हर कोई धन्यवाद। – LucasTizma

1

उद्देश्य-सी में एक हेडर फ़ाइल (वास्तव में, #import को कॉल करने) की लागत क्या है?

संकलक इन फ़ाइलों को अनावश्यक रूप से पढ़ने के लिए बाहर हो सकता है। एक बार #import एड के बाद, प्रत्येक अनुवाद के लिए अतिरिक्त फ़ाइलों को पार्स, संकलित आदि की आवश्यकता होगी (उदा। .m फ़ाइल) यह आपके निर्माण और लिंक के समय को और अधिक बनाने में दिखाई दे रही है। 10 गुना लंबा आश्चर्यजनक नहीं है।

मैं लगातार विभिन्न स्थानों पर एक ही शीर्षलेख सहित थक गया हूं, इसलिए मैंने केवल ग्लोबल रेफरेंस एच फाइल बनाने का फैसला किया जिसमें कई सामान्य संदर्भित शीर्षलेख शामिल हैं।

आमतौर पर, यह एक बहुत ही खराब दृष्टिकोण है। आम समस्या यह है कि जब भी GlobalReferences.h द्वारा शामिल की गई किसी भी फाइल को बदल दिया जाता है, तो आपकी पूरी परियोजना और सभी निर्भरताओं के बीच पुनर्निर्मित, रिंकिंक आदि की आवश्यकता होगी।

मेरी प्राथमिकता प्रोग्राम को छोटे पुस्तकालयों या संकुलों में अलग करना है जहां यह परस्पर निर्भरता मौजूद है (उदा। StoreKit.framework एक छोटा पैकेज/लाइब्रेरी है) - लेकिन हेडर में उन पुस्तकालयों/ढांचे/पैकेजों को भरना कुछ भी हल नहीं करता है। साथ ही, आगे की घोषणाएं और कक्षा निरंतरता में आपके डेटा को संग्रहीत करना या @implementation निर्भरता को काफी कम कर सकता है (क्योंकि आप केवल आवश्यक अनुवादों के लिए लाइब्रेरी/हेडर को शामिल करने का स्थानीयकरण कर सकते हैं)।

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

क्या अन्य फ़ाइलों के संदर्भों को शामिल करने के लिए कोई सराहनीय लागत है यदि उनका उपयोग भी नहीं किया जाता है?

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