कुछ बार जब प्रोग्रामिंग हम परिभाषित या घोषित करते हैं, परिभाषाएं, चर, मैक्रोज़ और डेटा संरचनाएं शामिल करते हैं। लेकिन उसके बाद कभी भी इसका इस्तेमाल न करें।क्या कंपाइलर्स अप्रयुक्त कार्यों, परिभाषाओं, चर, मैक्रोज़, आदि शामिल हैं
यह निर्भर करता है:
मैक्रो संकलक द्वारा पाठ कार्यक्रम बदल रहे हैं। वे उन पाठों के अलावा किसी अन्य चीज का प्रतिनिधित्व नहीं करते हैं जो उन्हें बदलते हैं, और संकलन समय से परे नहीं रहते (जब तक ... नीचे देखें)।
स्थानीय चर और ऐसे संभावित रूप से हटा दिए जाते हैं, अगर उनके पास गैर-तुच्छ कन्स्ट्रक्टर या विनाशक नहीं है। (आप नहीं है कुछ scoped_lock तरह हटा दिया सिर्फ इसलिए कि तुम क्या चाहते हैं नहीं संदर्भ इसे बाद में कोड में।) चर और कार्यों आंतरिक लिंकेज के साथ (जैसे कीवर्ड static साथ नाम स्थान दायरे में परिभाषित के लिए एक ही रखती है)। ज्यादातर मामलों में, हालांकि, ऐसी वस्तुओं के लिए आवश्यक संसाधन न्यूनतम है, और बचत नगण्य है।
कार्य थोड़ा अलग हैं, और निर्भर हैं। वर्चुअल फ़ंक्शन को आम तौर पर "प्रयुक्त" माना जाएगा यदि उसके पास इसके प्रकार का उदाहरण है, और यह लगभग निश्चित रूप से उपस्थित होगा, भले ही कभी नहीं कहा जाता है।
इसके अलावा (और यह वैश्विक चर पर भी लागू होता है): यह लिंकर तक है। अधिकांश लिंकर्स की ग्रैन्युलरिटी ऑब्जेक्ट फ़ाइल है जो "अनुवाद इकाई" को संकलित करने के परिणामस्वरूप होती है: ऑब्जेक्ट फ़ाइल या तो आपके प्रोग्राम का हिस्सा है या नहीं। यदि आप ऑब्जेक्ट फ़ाइल को शामिल करने के लिए लिंकर को बताएं, तो आपको उसमें सबकुछ प्राप्त करना चाहिए। यदि आप ऑब्जेक्ट फ़ाइल को ए (स्थिर) लाइब्रेरी में डालते हैं, और लिंकर को इसका उपयोग करने के लिए कहें, तो लिंकर ऑब्जेक्ट फ़ाइल को आपके प्रोग्राम में शामिल करेगा यदि केवल तभी होता है जब यह अन्यथा अनसुलझा बाहरी हो। लेकिन अगर यह ऑब्जेक्ट फ़ाइल को शामिल करता है, तो यह आमतौर पर सभी को शामिल करेगा। (कोई भी अच्छी लाइब्रेरी प्रत्येक गैर वर्चुअल फ़ंक्शन को में एक अलग ऑब्जेक्ट फ़ाइल डाल देगी, इसलिए आपको अपनी आवश्यकता से अधिक नहीं मिलता है।)
इस संबंध में, डीएलएल ऑब्जेक्ट फाइलों की तरह व्यवहार करता है (उनके नाम के बावजूद)। यदि आप अपनी ऑब्जेक्ट फ़ाइलों को एक डीएलएल में लिंक करते हैं, तो प्रोग्राम जो इसका उपयोग करता है, वह सभी डीएलएल, या कोई भी नहीं मिलेगा।
अंत में: हालांकि आपके प्रोग्राम का हिस्सा नहीं है, ऑब्जेक्ट फाइलें और अंतिम निष्पादन योग्य में अक्सर प्रतीकात्मक जानकारी होगी; सर्वोत्तम सिस्टम मैक्रोज़ से संबंधित जानकारी को भी बनाए रखेंगे, ताकि डीबगर लिखने के तरीके को प्रदर्शित कर सके। (मैक्रोज़ के साथ यह कितना दूर कर सकता है बहस योग्य है।)
यदि या तो संकलक या लिंकर देख सकता है कि सी फ़ंक्शंस या सी चर के लिए कोई संदर्भ नहीं है, तो वे उन अप्रयुक्त चीज़ों को हटा सकते हैं (और आमतौर पर करते हैं)।
अप्रयुक्त मैक्रो परिभाषा इसे संकलित कोड में बिल्कुल नहीं बनाती है। और यह टाइपिफ और इसी तरह के लिए रखता है।
हालांकि, कार्यक्रमों के असेंबली हिस्सों में लागू अप्रयुक्त कोड और डेटा को हटाने के लिए मुश्किल है।
और यह कुछ संदर्भित चर या कुछ कोड का उपयोग या निष्पादित होने के लिए हमेशा संकलक के लिए स्पष्ट नहीं है।
तो, हाँ, इन दिनों, स्पष्ट रूप से अप्रयुक्त सामग्री को हटा दिया गया है।
देखें यह अप्रयुक्त सामग्री पर निर्भर करता है। वैश्विक दायरे में कुछ भी (और जिसमें अधिकांश फ़ंक्शंस शामिल हैं) केवल लिंकर द्वारा हटाया जा सकता है, और अधिकांश लिंकर्स की ग्रैन्युलरिटी ऑब्जेक्ट फ़ाइल है, जैसे ही ऑब्जेक्ट फ़ाइल आपके प्रोग्राम में शामिल की जाती है, आपको उसमें सबकुछ मिलता है । आम तौर पर, जो हटाया जाएगा वह स्थानीय चर और ऐसे है; वैसे भी जिनके लिए कई संसाधनों की आवश्यकता नहीं है। –
@ जेम्ससांज मैंने लिंकर्स का जिक्र किया था। ग्रैन्युलरिटी को एक ऑब्जेक्ट फ़ाइल (अनुवाद इकाई) नहीं होना चाहिए। –
यह होना जरूरी नहीं है, लेकिन यह लगभग हमेशा होता है। व्यावहारिक रूप से, एक कारण है कि लाइब्रेरी कोड का निर्माण करते समय अनुभवी प्रोग्रामर प्रत्येक समारोह को एक अलग स्रोत फ़ाइल में डालते हैं। –
जीसीसी हमेशा '-Wall' के साथ अप्रयुक्त चर चेतावनी फेंकता है, इसलिए मैं कल्पना करता हूं। – Blender
मैक्रोज़ अप्रासंगिक हैं, लेकिन http://stackoverflow.com/q/6215782/390913 – perreal