C / C ++ में हेडर फ़ाइल ऑर्डर शामिल है

Question

फ़ाइलों को किस क्रम में निर्दिष्ट किया जाना चाहिए, यानी एक से पहले एक हेडर सहित क्या कारण हैं?

उदाहरण के लिए, क्या सिस्टम फ़ाइलें, एसटीएल और बूस्ट स्थानीय शामिल होने से पहले या बाद में फ़ाइलें शामिल हैं?

Comments

और नीचे दिए गए उत्तरों की अधिकता है, इसलिए जावा डेवलपर्स ने अलग हेडर के खिलाफ निर्णय लिया। :-) कुछ विशेष रूप से अच्छे उत्तर, हालांकि, विशेष रूप से यह सुनिश्चित करने के लिए कि आपकी स्वयं की हेडर फाइलें अकेले खड़ी हो सकती हैं।

— क्रिस के

मुझे यह पसंद है कि ऐसे प्रश्न जिनके पास 100+ वोट हैं और जो कुछ लोगों के लिए दिलचस्प हैं, वे "रचनात्मक नहीं" के रूप में बंद हो जाते हैं।

— एंड्रियास

एक अत्यधिक की सिफारिश की पढ़ें: cplusplus.com/forum/articles/10627

— Kalsan

@ मर्ट, SO दृढ़ता से सूप की याद दिलाता है नाजी समुदाय: या तो आप कुछ बहुत ही सख्त नियमों का पालन करते हैं, या "आपके लिए कोई उचित उत्तर / टिप्पणियां नहीं!"। फिर भी, अगर किसी को किसी भी तरह से प्रोग्रामिंग से संबंधित समस्या है, तो यह (आमतौर पर) जाने वाली पहली साइट है ..

— इमैगो

Answer 1

मुझे नहीं लगता कि जब तक यह संकलित है, तब तक एक अनुशंसित आदेश नहीं है! क्या कष्टप्रद है जब कुछ हेडर को पहले शामिल करने के लिए अन्य हेडर की आवश्यकता होती है ... यह हेडर के साथ एक समस्या है, जिसमें शामिल के क्रम के साथ नहीं है।

मेरी व्यक्तिगत प्राथमिकता स्थानीय से वैश्विक स्तर तक जाने की है, प्रत्येक वर्णमाला के क्रम में है, अर्थात:

1. h इस cpp फ़ाइल के अनुरूप फ़ाइल (यदि लागू हो)
2. एक ही घटक से हेडर,
3. अन्य घटकों से हेडर,
4. सिस्टम हेडर।

1 के लिए मेरा तर्क यह है कि यह साबित होना चाहिए कि प्रत्येक हेडर (जिसके लिए एक सीपीपी है) को #includeकिसी और चीज के बिना डी किया जा सकता है (टर्मिनस टेक्निकस: हेडर "स्व-निहित" है)। और बाकी सिर्फ तार्किक रूप से वहाँ से प्रवाह करने लगता है।

Comments

तुम्हारे जैसे ही बहुत कुछ है, सिवाय इसके कि मैं वैश्विक से नीचे स्थानीय में जाता हूं, और स्रोत फ़ाइल के अनुरूप हेडर विशेष उपचार प्राप्त नहीं करता है।

— जॉन प्यूरी

@ जॉन: मैं कहूंगा कि यह बहुत विपरीत है! :-) मैं तर्क दूंगा कि आपका तरीका छिपी हुई निर्भरता का परिचय दे सकता है, कह सकते हैं कि यदि myclass.cpp में <string> शामिल है तो <myclass.h>, बिल्ड टाइम पर पकड़ने का कोई तरीका नहीं है कि myclass.h स्वयं स्ट्रिंग पर निर्भर हो; इसलिए यदि बाद में आप या किसी और ने myclass.h को शामिल किया है, लेकिन आपको स्ट्रिंग की आवश्यकता नहीं है, तो आपको एक त्रुटि मिलेगी जिसे या तो सीपीपी या हेडर में ही ठीक करने की आवश्यकता है। लेकिन मुझे यह जानने में दिलचस्पी होगी कि क्या लोग सोचते हैं कि लंबे समय में बेहतर काम करेगा ... आप अपने प्रस्ताव के साथ उत्तर क्यों नहीं देते हैं और हम देखेंगे कि कौन "जीतता है"? ;-)

— स्क्वेलर्ट

सामान्य ऑर्डरिंग के लिए विशिष्ट वह है जो मैं इस समय डेव अब्राहम की सिफारिश से उपयोग करता हूं। और वह उसी कारण को नोट करता है जैसे @ लापता के हेडर को रोशन करने के लिए स्थानीय से लेकर अधिक सामान्य स्रोतों में शामिल है। महत्वपूर्ण कुंजी यह है कि आप 3 पार्टी, और सिस्टम लाइब्रेरी की तुलना में उन गलतियों को करने की अधिक संभावना रखते हैं।

— ग्रेफिकरोबॉट

@PaulJansen यह एक बुरा अभ्यास है और एक ऐसी तकनीक का उपयोग करना अच्छा है जो इसके साथ उड़ने की अधिक संभावना है ताकि खराब अभ्यास को छिपाए जाने के बजाय तय किया जा सके। स्थानीय से वैश्विक FTW

— bames53

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

— bames53

Answer 2

ध्यान रखने वाली बड़ी बात यह है कि आपके हेडर को पहले शामिल किए जा रहे अन्य हेडर पर निर्भर नहीं होना चाहिए। इसका बीमा करने का एक तरीका यह है कि आप अपने हेडर को किसी अन्य हेडर से पहले शामिल करें।

"सी ++ में सोच" विशेष रूप से इसका उल्लेख करते हैं, लैकोस का "बड़े पैमाने पर सी ++ सॉफ्टवेयर डिज़ाइन" का संदर्भ देते हुए:

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

यह कहना है, निम्नलिखित क्रम में शामिल करें:

1. इस कार्यान्वयन के लिए प्रोटोटाइप / इंटरफ़ेस हेडर (यानी, .h / .h फ़ाइल जो इस .cpp / -cc फ़ाइल से मेल खाती है)।
2. आवश्यकतानुसार अन्य हेडर।
3. अन्य गैर-मानक, गैर-सिस्टम पुस्तकालयों (उदाहरण के लिए, Qt, Eigen, आदि) से हेडर।
4. अन्य "लगभग-मानक" पुस्तकालयों के प्रमुख (उदाहरण के लिए, बूस्ट)
5. मानक C ++ हेडर (उदाहरण के लिए, iostream, कार्यात्मक, आदि)
6. मानक सी हेडर (उदाहरण के लिए, cstdint, dirent.h, आदि)

यदि किसी भी हेडर में इस क्रम में शामिल होने के साथ कोई समस्या है, तो उन्हें (यदि आपका) ठीक करें या उनका उपयोग न करें। बहिष्कार पुस्तकालयों कि स्वच्छ हेडर नहीं लिखते हैं।

Google का C ++ स्टाइल गाइड लगभग उल्टा तर्क देता है , जिसमें वास्तव में कोई औचित्य नहीं है; मैं व्यक्तिगत रूप से लैकोस दृष्टिकोण का पक्ष लेता हूं।

Comments

अब तक, Google C ++ स्टाइल गाइड , लैक्स के सुझाव के बाद, पहले संबंधित हेडर फ़ाइल सहित सिफारिश करता है।

— फ़िलिप बर्टेक

आप पहले संबंधित हेडर से बहुत आगे नहीं बढ़ सकते हैं क्योंकि एक बार जब आप अपने इन-प्रोजेक्ट हेडर को शामिल करना शुरू कर देते हैं तो आप बहुत अधिक सिस्टम निर्भरता में खींचने जा रहे हैं।

— मीका

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

— नाथन पॉल सिमंस

Answer 3

मैं दो सरल नियमों का पालन करता हूं जो अधिकांश समस्याओं से बचते हैं:

1. सभी हेडर (और वास्तव में किसी भी स्रोत फ़ाइलें) में वे शामिल होने चाहिए जो उन्हें चाहिए। उन्हें चीजों सहित अपने उपयोगकर्ताओं पर भरोसा नहीं करना चाहिए ।
2. एक सहायक के रूप में, सभी हेडर में गार्ड शामिल होने चाहिए ताकि वे ऊपर दिए गए नियम के अति-महत्वाकांक्षी आवेदन द्वारा कई बार शामिल न हों।

मैं निम्नलिखित दिशानिर्देशों का भी पालन करता हूं:

1. एक विभाजन रेखा के साथ पहले सिस्टम हेडर (stdio.h, आदि) शामिल करें।
2. उन्हें तार्किक रूप से समूहित करें।

दूसरे शब्दों में:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

हालांकि, दिशानिर्देश होने के नाते, यह एक व्यक्तिपरक बात है। दूसरी ओर, मैं सख्ती से लागू करता हूं, यहां तक ​​कि गार्ड और समूहीकृत के साथ 'रैपर' हेडर फ़ाइलों को प्रदान करने के बिंदु तक भी शामिल है अगर कुछ अप्रिय तीसरे पक्ष के डेवलपर मेरी दृष्टि की सदस्यता नहीं लेते हैं :-)

Comments

+1 "सभी हेडर (और वास्तव में किसी भी स्रोत फ़ाइलें) में वे शामिल होने चाहिए जो उन्हें चाहिए। उन्हें चीजों सहित अपने उपयोगकर्ताओं पर भरोसा नहीं करना चाहिए।" फिर भी बहुत से लोग इस निहित समावेशी व्यवहार पर भरोसा करते हैं, उदाहरण के लिए, NULL के साथ और <cstddef> को शामिल नहीं करते हैं। इस कोड को पोर्ट करने की कोशिश करने और NULL पर संकलित त्रुटियां होने के कारण यह बहुत कष्टप्रद है (एक कारण जो मैं अभी 0 उपयोग करता हूं)।

— 3

आप पहले सिस्टम हेडर क्यों शामिल करते हैं? यह बेहतर होगा कि आपके पहले नियम की वजह से आसपास क्यों।

— झस १४'१५ को २३:०२

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

— हमीज़ेल ने इस्तीफा दे दिया

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

— Zoso

Answer 4

दीवार में अपनी ईंट जोड़ने के लिए।

1. प्रत्येक हेडर को आत्मनिर्भर होने की आवश्यकता होती है, जिसे केवल तभी जांचा जा सकता है जब उसे कम से कम एक बार पहले शामिल किया गया हो
2. किसी को गलती से प्रतीक (स्थूल, प्रकार, आदि) शुरू करके तीसरे पक्ष के हेडर के अर्थ को संशोधित नहीं करना चाहिए।

इसलिए मैं आमतौर पर इस तरह से जाता हूं:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

प्रत्येक समूह अगले एक से एक रिक्त रेखा द्वारा अलग हो गया:

• पहले इस cpp फ़ाइल के लिए हैडर (स्वच्छता जाँच)
• सिस्टम हेडर
• तृतीय-पक्ष हेडर, निर्भरता क्रम द्वारा आयोजित
• प्रोजेक्ट हेडर
• निजी हेडर प्रोजेक्ट करें

यह भी ध्यान दें कि, सिस्टम हेडर के अलावा, प्रत्येक फ़ाइल अपने नेमस्पेस के नाम के साथ एक फ़ोल्डर में है, सिर्फ इसलिए कि उन्हें इस तरह से ट्रैक करना आसान है।

Comments

ताकि अन्य हेडर फाइलें उनके द्वारा प्रभावित न हों। दोनों उन सिस्टम हेडर को परिभाषित करते हैं जो (दोनों एक्स शामिल हैं और विंडोज में शामिल हैं, #defineजो अन्य कोड को गड़बड़ करते हैं) और अंतर्निहित निर्भरता को रोकने के लिए खराब हैं । उदाहरण के लिए, यदि हमारी कोड बेस हेडर फाइल foo.hवास्तव में निर्भर करती है, <map>लेकिन हर जगह इसका इस्तेमाल .ccफाइलों में <map>होता है, तो पहले से ही शामिल होने के लिए हुआ, हम शायद नोटिस नहीं करेंगे। जब तक किसी foo.hको पहले शामिल किए बिना शामिल करने की कोशिश की <map>। और फिर वे नाराज हो जाते।

@ 0A0D: दूसरा मुद्दा यहां के क्रम में कोई समस्या नहीं है, क्योंकि प्रत्येक .hमें कम से कम एक है .cppजो इसे पहले शामिल करता है (वास्तव में, मेरे व्यक्तिगत कोड में यूनिट परीक्षण में पहले इसे शामिल किया गया है, और स्रोत कोड ने इसे अपने सही समूह में शामिल किया है )। प्रभावित न होने के संबंध में, यदि किसी भी हेडर में शामिल है, <map>तो बाद में शामिल सभी हेडर वैसे भी प्रभावित होते हैं, इसलिए यह मेरे लिए एक हारी हुई लड़ाई लगती है।

— Matthieu M.

बेशक, यही कारण है कि मैं नियमित रूप से घूमता रहता हूं और पुराने कोड (या यहां तक ​​कि नए कोड) को ठीक करता हूं, जिसमें अनावश्यक रूप से शामिल होने की आवश्यकता होती है क्योंकि यह सिर्फ बिल्ड टाइम को ड्राइव करता है।

@MatthieuM। मैं आपकी बात के पीछे तर्क को जानना चाहूंगा Header corresponding to this cpp file first (sanity check)। क्या कुछ विशेष है अगर #include "myproject/example.h"सभी को शामिल किया गया है?

— MNS

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

— मथिउ एम।

Answer 5

मेरा सुझाव है:

1. आपके द्वारा निर्मित .cc मॉड्यूल के हेडर। (आपकी परियोजना में प्रत्येक हेडर को यह सुनिश्चित करने में मदद करता है कि आपकी परियोजना में अन्य हेडर पर निहित निर्भरता नहीं है।)
2. C सिस्टम फाइलें।
3. C ++ सिस्टम फ़ाइलें।
4. प्लेटफ़ॉर्म / ओएस / अन्य हेडर फाइलें (जैसे win32, gtk, openGL)।
5. आपके प्रोजेक्ट की अन्य हेडर फाइलें।

और निश्चित रूप से, जहां संभव हो, प्रत्येक अनुभाग के भीतर वर्णमाला क्रम।

#includeअपनी हेडर फ़ाइलों में अनावश्यक एस से बचने के लिए हमेशा आगे की घोषणाओं का उपयोग करें।

Comments

+1, लेकिन वर्णमाला क्यों? ऐसा कुछ लगता है जो आपको बेहतर महसूस करा सकता है, लेकिन इसका कोई व्यावहारिक लाभ नहीं है।

— बेन

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

— I_am_jorf

Answer 6

मुझे पूरा यकीन है कि यह समझदार दुनिया में कहीं भी एक अनुशंसित अभ्यास नहीं है, लेकिन मुझे लाइन सिस्टम पसंद है जिसमें फ़ाइल नाम लंबाई, समान रूप से एक ही लंबाई के भीतर क्रमबद्ध शामिल है। इस तरह:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

मुझे लगता है कि अन्य लोगों से पहले अपने स्वयं के हेडर को शामिल करना एक अच्छा विचार है, शामिल-ऑर्डर निर्भरता की शर्म से बचने के लिए।

Comments

मुझे उस क्रम में दूसरे, तीसरे और फिर पहले अक्षर से मिलकर एक कुंजी का उपयोग करके अपने हेडर को सॉर्ट करना पसंद है :-) तो वेक्टर, सेट, एल्गोरिदम, आपके उदाहरण के लिए कार्यात्मक।

— paxdiablo

@paxdiablo, टिप के लिए धन्यवाद। मैं इसका उपयोग करने पर विचार कर रहा हूं, लेकिन मुझे चिंता है कि यह फाइलनामों के ढेर को अस्थिर करने और खत्म होने की संभावना को समाप्त कर सकता है। कौन जानता है कि इसमें शामिल होने पर क्या हो सकता है - शायद यहां तक ​​कि windows.h।

— क्लेस्ट्रॉस्क

लंबाई द्वारा क्रमबद्ध ? पागलपन!

— जेम्स मैकनेलिस

पहले के लिए +1। यह वास्तव में समझ में आता है, अगर आपको अपनी फ़ाइल के साथ हेडर को नेत्रहीन रूप से खोजने की आवश्यकता है तो यह वर्णमाला की तुलना में बहुत बेहतर है।

— कुगेल

Answer 7

यह व्यक्तिपरक नहीं है। सुनिश्चित करें कि आपके हेडर #includeविशिष्ट क्रम में d होने पर निर्भर नहीं हैं । आप सुनिश्चित कर सकते हैं कि इससे कोई फर्क नहीं पड़ता कि आप एसटीएल या बूस्टर हेडर को किस क्रम में शामिल करते हैं।

Comments

मैं कोई निहित निर्भरता नहीं मान रहा था

— Anycorn

हां, लेकिन संकलक इस धारणा को नहीं बना सकता है, इसलिए #include <A>, <B> कभी भी #include <B>, <A> के समान नहीं है, जब तक कि उन्हें संकलित नहीं किया गया है।

— मिखाइल

Answer 8

पहले शीर्ष लेख को .cpp के अलावा शामिल करें ... दूसरे शब्दों में, कुछ भी source1.cppशामिल करने source1.hसे पहले शामिल करना चाहिए । एकमात्र अपवाद जो मैं सोच सकता हूं, जब पूर्व-संकलित हेडर के साथ MSVC का उपयोग कर रहे हैं, तो आप stdafx.hकिसी भी अन्य चीज से पहले शामिल होने के लिए मजबूर हैं ।

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

उदाहरण:

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

MSVC उपयोगकर्ता: मैं पूर्व संकलित हेडर का उपयोग करने की दृढ़ता से सलाह देता हूं। इसलिए, #includeमानक हेडर (और अन्य हेडर जो कभी बदलने नहीं जा रहे हैं) के लिए सभी निर्देशों को स्थानांतरित करें stdafx.h।

Answer 9

सबसे विशिष्ट से कम से कम विशिष्ट को शामिल करें, .cpp के लिए इसी .hpp से शुरू करें, अगर ऐसा मौजूद है। इस तरह, हेडर फ़ाइलों में छिपी निर्भरताएं जो आत्मनिर्भर नहीं हैं, वे प्रकट हो जाएंगी।

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

Answer 10

यह मानक से परे कई तत्वों के साथ, सी / सी ++ दुनिया में एक कठिन सवाल है।

मुझे लगता है कि जब तक यह संकलित नहीं होता है, हेडर फ़ाइल ऑर्डर एक गंभीर समस्या नहीं है।

मेरा विचार है: यदि उन सभी शीर्ष लेखों में प्रतीकों का कोई विरोध नहीं है, तो कोई भी आदेश ठीक है, और शीर्ष लेख पर निर्भरता समस्या बाद में #include पंक्तियों को त्रुटिपूर्ण .h में जोड़कर तय की जा सकती है।

असली परेशानी तब होती है जब कुछ हेडर ऊपर की चीज़ों के अनुसार अपनी कार्रवाई (# एफ़आई शर्तों की जाँच करके) बदल देते हैं।

उदाहरण के लिए, VS2005 में stddef.h में है:

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

अब समस्या: यदि मेरे पास एक कस्टम हेडर ("custom.h") है, जिसे कई कंपाइलरों के साथ उपयोग करने की आवश्यकता है, जिसमें कुछ पुराने भी शामिल हैं जो offsetofउनके सिस्टम हेडर में प्रदान नहीं करते हैं, मुझे अपने हेडर में लिखना चाहिए:

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

और सभी सिस्टम हेडर के #include "custom.h" बाद उपयोगकर्ता को बताना सुनिश्चित करें , अन्यथा, offsetofstddef.h की लाइन मैक्रो रिडिफाइनमेंट त्रुटि को मुखर करेगी।

हम अपने करियर में इस तरह के किसी भी मामले को पूरा नहीं करने की प्रार्थना करते हैं।