हेडर के पीछे तर्क क्या है?

Question

मुझे हेडर रखने का बिंदु बिल्कुल समझ में नहीं आता है; ऐसा लगता है कि डीआरवाई सिद्धांत का उल्लंघन! एक शीर्षलेख में सभी जानकारी कार्यान्वयन में निहित है (हो सकता है)।

Answer 1

यह संकलन प्रक्रिया को सरल बनाता है। जब आप स्वतंत्र रूप से इकाइयों को संकलित करना चाहते हैं, तो आपको उन हिस्सों का वर्णन करने के लिए कुछ चाहिए जो अन्य सभी फ़ाइलों की पूरी तरह से आयात किए बिना लिंक किए जाएंगे।

यह कोड छिपाने के लिए भी अनुमति देता है। कोई अन्यथा कार्यान्वयन वितरित किए बिना कार्यक्षमता का उपयोग करने की अनुमति देने के लिए एक शीर्षलेख वितरित कर सकता है।

अंत में, यह कार्यान्वयन से इंटरफ़ेस को अलग करने को प्रोत्साहित कर सकता है।

इन समस्याओं को हल करने का एकमात्र तरीका नहीं है, लेकिन 30 साल पहले वे एक अच्छे थे। हम शायद आज एक भाषा के लिए हेडर फाइलों का उपयोग नहीं करेंगे, लेकिन 200 9 में उनका आविष्कार नहीं किया गया था।

Answer 2

और यदि आप किसी और को कार्यान्वयन के बिना अपनी लाइब्रेरी का उपयोग करने की घोषणा करना चाहते हैं तो क्या होगा?

जैसा कि एक और उत्तर बताता है - हेडर के लिए मूल कारण प्लेटफॉर्म पर बहुत सरल और सीमित उपकरणों के साथ पार्स/संकलन को आसान बनाना था। यह 2 फ्लॉपीज़ वाली मशीन रखने के लिए एक शानदार कदम था ताकि आप एक और आपके कोड को दूसरे पर बना सकें - बनाई गई चीजों को बहुत आसान बना दिया जाए।

Answer 3

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

अंतरिक्ष या संकलन की समय जटिलता को कम करने वाली कुछ भी बड़ी जीत थी। और हेडर दोनों करते हैं।

Answer 4

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

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

यदि सी, सी ++, & सी, संपन्न रहें (जाहिर है कि वे आज भी ठीक कर रहे हैं ;-), और हेडर मैन्युअल रूप से लिखने के लिए आपकी तरह की मांग बढ़ती है, अंततः कंपाइलर लेखकों को "हेडर पीढ़ी" विकल्प, और "दोनों दुनिया के सर्वश्रेष्ठ" सैद्धांतिक नहीं रहेंगे!-)

Answer 5

आपके पास जावा में हेडर नहीं हैं - लेकिन आपके पास इंटरफेस हैं और मैं प्रत्येक गंभीर जावा गुरु आपको अन्य परियोजनाओं/प्रणालियों द्वारा इंटरफ़ेस और कार्यान्वयन के रूप में उपयोग की जाने वाली किसी भी चीज़ को परिभाषित करने की अनुशंसा करता हूं।

चलिए एक जावा इंटरफ़ेस परिभाषा को कॉल हस्ताक्षर, टाइप परिभाषाएं और contants देखते हैं।

अधिकांश सी शीर्षलेख फ़ाइलों में कॉल हस्ताक्षर, प्रकार परिभाषाएं और स्थिरांक होते हैं।

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

int function target() { 
    // Default for shoot 
    return FOOT; 
} 

Answer 6

विस्तार के लिए पढ़ें this

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

सी मानक पुस्तकालय और सी ++ मानक पुस्तकालय परंपरागत रूप से हेडर फ़ाइलों में उनके मानक कार्यों की घोषणा करता है।

Answer 7

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

तो जब सी मॉड्यूलरिटी के लिए सामान्य डिज़ाइन पैटर्न आया तो "कोई भी जांच नहीं करता" था। एक प्रतिबंध हो सकता है कि .text प्रतीक केवल .text और .data से .data से लिंक कर सकते हैं, लेकिन वह था। यही है, दिन के कंपाइलर्स ने आम तौर पर एक समय में एक स्रोत फ़ाइल को संसाधित किया और फिर लिंकर्स उन्हें भाग्यशाली थे, अगर आप भाग्यशाली थे, "मैं एक फ़ंक्शन प्रतीक हूं" बनाम "मैं हूं एक डेटा प्रतीक "।

तो वास्तव में संकलक होने का विचार समझने वाली चीज़ को कुछ हद तक नया था।

आज भी, यदि आप पूरी तरह से फर्जी हेडर बनाते हैं, तो कोई भी आपको AOT compilers में नहीं पकड़ता है। सीएलआर भाषाओं और जावा जैसी चतुर चीजें वास्तव में कक्षा फ़ाइलों में चीजें एन्कोड करती हैं।

तो हाँ, लंबे समय तक, शायद हमारे पास हेडर फाइल नहीं होंगी।

Answer 8

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

रखते हुए स्रोत, शीर्ष लेख और सिंक में अतिरिक्त दस्तावेज़ उपलब्ध अभी भी कीड़े का एक और सकता है ...

Answer 9

जब आप शीर्ष लेख और स्रोत फ़ाइलों में कोड को विभाजित आप घोषणा और परिभाषा विभाजित करते हैं।जब आप हेडर फाइलों में देखते हैं तो आप देख सकते हैं कि आपके पास क्या है और यदि आप कार्यान्वयन विवरण देखना चाहते हैं तो आप स्रोत फ़ाइल पर जाते हैं।