प्रति स्रोत फ़ाइल शीर्षलेख

Question

मैं प्रत्येक स्रोत फ़ाइल विधि के प्रति एक शीर्षलेख के पीछे उद्देश्य को समझने की कोशिश कर रहा हूं। जैसा कि मैंने इसे देखा है, हेडर फ़ंक्शन घोषणाओं, typedef और मैक्रो का उपयोग करने वाली कई फ़ाइलों के बीच साझा करने के लिए हैं। जब आप अपनी .c फ़ाइल के लिए हेडर फ़ाइल बनाते हैं तो इसका नुकसान होता है कि प्रत्येक बार जब आप फ़ंक्शन घोषणा या मैक्रो देखना चाहते हैं तो आपको हेडर फ़ाइल का संदर्भ देना होगा, और आम तौर पर यह आसान है कि सब कुछ एक स्रोत फ़ाइल में है (नहीं बिल्कुल सॉफ्टवेयर, बिल्कुल)।

तो प्रोग्रामर इस विधि का उपयोग क्यों करते हैं?

Answer 1

परिभाषाओं से (जो एक ही स्थान पर होना चाहिए) से सी अलग-अलग घोषणाओं (जो कार्यों का उपयोग करने वाली प्रत्येक .c फ़ाइल में उपलब्ध होना चाहिए) में शीर्षलेख फ़ाइलें। इसके अलावा, वे थोड़ा मॉड्यूलरिटी प्रदान करते हैं, क्योंकि आप केवल सार्वजनिक इंटरफ़ेस को हेडर फ़ाइल में डाल सकते हैं, और फ़ंक्शन और स्थिर चर का उल्लेख नहीं करते हैं जो .c फ़ाइल में आंतरिक होना चाहिए। यह एक सार्वजनिक इंटरफ़ेस और निजी कार्यान्वयन प्रदान करने के लिए फ़ाइल सिस्टम का उपयोग करता है।

एक .h फ़ाइल में एक .h फ़ाइल का अभ्यास अधिकतर सुविधा है। इस तरह, आप जानते हैं कि घोषणाएं हैं।एच फ़ाइल, और इसी .c फ़ाइल में परिभाषाओं।

Answer 2

आम तौर पर स्रोत फ़ाइल विधि के लिए एक शीर्षलेख का अर्थ है कि आप उस शीर्षलेख में उस संकलन इकाई से केवल फ़ंक्शंस घोषित करते हैं।

इस तरह आप घोषणाओं के साथ प्रदूषित नहीं करते हैं जिनकी आपको आवश्यकता नहीं है। (बड़े सॉफ्टवेयर प्रोजेक्ट में एक समस्या हो सकती है)

अलग संकलन इकाइयों के लिए, ये संकलन को गति देते हैं और अगर निजी प्रतीकों को स्थिर घोषित किया जाता है तो टकराव से बचने में आपकी मदद कर सकते हैं।

Answer 3

आपको प्रति स्रोत फ़ाइल में एक शीर्षलेख की आवश्यकता नहीं है। प्रति मॉड्यूल में एक हेडर, जिसमें सार्वजनिक इंटरफ़ेस होता है, और शायद उस मॉड्यूल में फ़ाइलों के बीच साझा निजी घोषणा वाले अतिरिक्त हेडर आदि।

Answer 4

क्योंकि, जैसा कि आपने स्वयं कहा था, "संपूर्ण सॉफ़्टवेयर" को एक स्रोत फ़ाइल में रखना संभव नहीं है।

यदि आपका प्रोग्राम बहुत छोटा है, तो हाँ सब कुछ एक .c फ़ाइल में डालने के लिए आसान है। चूंकि आपका प्रोग्राम बड़ा हो जाता है, इसलिए विभिन्न कार्यों को अलग-अलग .c फ़ाइलों में एक साथ रखकर चीजों को व्यवस्थित करना सहायक हो जाता है। इसके अलावा, .h फाइलों में आप उन फ़ाइलों की घोषणाओं को अस्वीकार कर सकते हैं जो हैं जो अन्य .c फ़ाइलों में चीजों द्वारा उपयोग किए जाने के लिए हैं। यदि किसी .c फ़ाइल में ऐसी कोई भी चीज़ नहीं है जो स्वयं के बाहर पहुंच योग्य हो, तो उसे कोई शीर्षलेख की आवश्यकता नहीं है।

उदाहरण के लिए, यदि .c में foo() और fooHelper() फ़ंक्शन है, लेकिन foo() को छोड़कर कोई भी व्यक्ति fooHelper() को सीधे कॉल करने के लिए नहीं है, तो foo() और fooHelper() को foo.c में डालकर, केवल foo.h में foo() की घोषणा डालना, और fooHelper() को स्थिर के रूप में घोषित करना, यह आपके प्रोग्राम के अन्य हिस्सों को केवल foo() तक पहुंचने के लिए प्रोत्साहित करने में मदद करता है और fooHelper() के बारे में नहीं जानना चाहिए या उसकी परवाह नहीं करनी चाहिए। Encapsulation के एक गैर वस्तु उन्मुख रूप की तरह।

अंत में, इंजन केवल उन फ़ाइलों को पुनर्निर्माण करने के लिए पर्याप्त स्मार्ट होते हैं जो अंतिम निर्माण के बाद बदल गए हैं, इसलिए एकाधिक .c फ़ाइलों में विभाजित होना (साझा करने की आवश्यकता रखने के लिए .h फ़ाइलों का उपयोग करके) गति को बढ़ाने में मदद करता है।

Answer 5

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

Answer 6

तार्किक, संरचित संगठन और छोटे स्रोत फ़ाइलों सक्षम:

• तेज़, बेहतर प्रोग्रामिंग - अधिक प्रबंधनीय और समझा जा सकता टुकड़ों में कोड तोड़ने को ढूंढना, समझने और प्रासंगिक कोड को संपादित करने में आता है।
• कोड पुन: उपयोगिता - कोड के विभिन्न "मॉड्यूल" को स्रोत/हेडर फ़ाइलों के समूहों में विभाजित किया जा सकता है जिन्हें आप विभिन्न प्रोग्रामों में आसानी से एकीकृत कर सकते हैं।
• बेहतर "encapsulation" - केवल .c फ़ाइलें जो विशेष रूप से उस हेडर को शामिल करती हैं, उनमें से विशेषताओं का उपयोग कर सकती हैं, जो आपको आपके कोड के विभिन्न हिस्सों के बीच संबंधों को कम करने में मदद करती है, जो मॉड्यूलरिटी को सहायता देती है। यह आपको कहीं से भी चीजों का उपयोग करने से नहीं रोकता है, लेकिन यह आपको इस बारे में सोचने में मदद करता है कि किसी विशेष सी फ़ाइल को किसी विशेष शीर्षलेख में घोषित फ़ंक्शंस तक पहुंचने की आवश्यकता क्यों होती है।
• एड्स टीमवर्क - दो प्रोग्रामर एक ही कोड फ़ाइल को बदलने की कोशिश कर रहे हैं, आमतौर पर समस्याएं (उदा। अनन्य ताले) या अतिरिक्त काम (जैसे कोड विलय) होते हैं जो एक-दूसरे को धीमा करते हैं।
• तेजी से संकलित - यदि आपके पास एक हेडर है तो हर बार जब आप इसमें बदलाव करते हैं तो आपको सब कुछ पुनः संयोजित करना होगा। कई छोटे शीर्षलेखों के साथ, केवल .c फाइलें जो # परिवर्तित हेडर को शामिल करती हैं, को पुनर्निर्मित किया जाना चाहिए।
• आसान रख-रखाव & पुनर्रचना - सभी उपरोक्त कारणों

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

Answer 7

प्रोग्रामर्स इस विधि का उपयोग। प्रत्येक फ़ाइल के प्रोटोटाइप के बारे में .h फ़ाइल "सच्चाई का एक बिंदु" है (देखें अपने आप को दोहराएं)।

(क्लाइंट कोड कोड है कि #include के आदेश निर्यात कार्यों का उपयोग करने के ज फ़ाइल है, लेकिन ज में किसी भी कार्य के लागू नहीं होता।)