#Include <filename> और #include "फ़ाइल नाम" में क्या अंतर है?

Question

सी और सी ++ प्रोग्रामिंग भाषाओं में, कोण कोष्ठक का उपयोग करने और एक includeबयान में उद्धरण का उपयोग करने के बीच अंतर क्या है ?

1. #include <filename>
2. #include "filename"

Comments

gcc.gnu.org/onbuildocs/gcc-2.95.3/cpp_1.html#SEC6

— किंवदंतियों 2k

कहाँ क्या जीसीसी देखो अपने हैडर फ़ाइलें ढूंढने के लिए

— theoretisch

विजुअल स्टूडियो के व्यवहार के लिए, कृपया देखें: docs.microsoft.com/en-us/cpp/preprocessor/…

— smwikipedia

Answer 1

व्यवहार में, अंतर उस स्थान पर है जहां प्रीप्रोसेसर शामिल फ़ाइल की खोज करता है।

के लिए #include <filename>पूर्वप्रक्रमक खोजें एक कार्यान्वयन निर्भर तरीके से, खोज निर्देशिका में सामान्य रूप से संकलक / आईडीई द्वारा पूर्व-निर्धारित। यह विधि आम तौर पर मानक पुस्तकालय हेडर फ़ाइलों को शामिल करने के लिए उपयोग की जाती है।

के लिए #include "filename"निर्देश युक्त फ़ाइल उसी निर्देशिका में पहले, और फिर पूर्वप्रक्रमक खोज खोज के लिए इस्तेमाल किया पथ का अनुसरण #include <filename>प्रपत्र। इस पद्धति का उपयोग आम तौर पर प्रोग्रामर-परिभाषित हेडर फ़ाइलों को शामिल करने के लिए किया जाता है।

खोज पथों पर GCC प्रलेखन में एक अधिक संपूर्ण विवरण उपलब्ध है ।

Comments

कथन: "प्रीप्रोसेसर उसी निर्देशिका में खोज करता है ..." व्यवहार में सही हो सकता है, लेकिन मानक बताता है कि नामित स्रोत फ़ाइल "कार्यान्वयन-परिभाषित तरीके से खोज की गई है"। PiCookie से उत्तर देखें।

— रिचर्ड कॉर्डन

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

— दान मोल्डिंग

"... प्रीप्रोसेसर उसी निर्देशिका में खोज करता है जिस फ़ाइल को शामिल किए जाने के लिए फ़ाइल संकलित की जा रही है।" यह कथन पूरी तरह से सही नहीं है। मुझे इस प्रश्न में दिलचस्पी थी क्योंकि मैं उत्सुक था कि वास्तविक उत्तर क्या है, लेकिन मुझे पता है कि यह सच नहीं है क्योंकि कम से कम जीसीसी के साथ जब आप एक अतिरिक्त शामिल पथ निर्दिष्ट करते हैं -I जो #include "फ़ाइल नाम के साथ निर्दिष्ट फ़ाइलों की खोज करेगा। एच "

— गेब्रियल दक्षिणी

जिन लोगों को जवाब पसंद नहीं है, कृपया एक व्यावहारिक उदाहरण दें, जहां यह गलत है।

— 0kcats

निश्चित रूप से पर्याप्त है, मैंने हाल ही में इन वाक्यविन्यासों को मिलाया है जब 'समान' पुस्तकालय से हेडर शामिल हैं और पुन: परिभाषित त्रुटियों के साथ समाप्त हुआ। यदि मैं सही ढंग से समझता हूं, #include <...>तो सिस्टम पर स्थापित पैकेज का #include "..."उपयोग किया और पास के रिपॉजिटरी संस्करण का उपयोग किया। मैं उन पीछे की ओर हो सकता है। किसी भी तरह से, पैकेज्ड हैडर में शामिल गार्ड को अंडरस्कोर के साथ उपसर्ग किया जाता है। (यह पैकेजों के लिए एक सम्मेलन हो सकता है या शायद दोनों को जानबूझकर रोकने का एक तरीका हो सकता है, हालांकि संस्करण क्वालिफ़ायर मेरे लिए कोई मतलब नहीं होगा।)

— जॉन पी

Answer 2

आपके कार्यान्वयन का प्रलेखन पढ़ने का एकमात्र तरीका पता है।

में सी मानक , खंड 6.10.2, अनुच्छेद 2 से 4 राज्य:

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include <h-char-sequence> new-line

  एक हेडर के लिए कार्यान्वयन-परिभाषित स्थानों के अनुक्रम को <और >सीमांकक के बीच निर्दिष्ट अनुक्रम द्वारा विशिष्ट रूप से पहचाना जाता है, और हेडर की संपूर्ण सामग्री द्वारा उस निर्देश के प्रतिस्थापन का कारण बनता है । स्थानों को कैसे निर्दिष्ट किया जाता है या हेडर की पहचान की गई है, कार्यान्वयन-परिभाषित है।

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include "q-char-sequence" new-line

  सीमांकक के बीच निर्दिष्ट अनुक्रम द्वारा पहचानी गई स्रोत फ़ाइल की संपूर्ण सामग्री द्वारा उस निर्देश के प्रतिस्थापन का कारण बनता "है। नामित स्रोत फ़ाइल को कार्यान्वयन-परिभाषित तरीके से खोजा जाता है। यदि यह खोज समर्थित नहीं है, या यदि खोज विफल हो जाती है, तो निर्देश पुन: मुद्रित किया जाता है जैसे कि यह पढ़ा जाता है

  #include <h-char-sequence> new-line

  >मूल निर्देश से समान निहित अनुक्रम ( वर्णों सहित , यदि कोई हो) के साथ।

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include pp-tokens new-line

  (यह दो पिछले रूपों में से एक से मेल नहीं खाता) की अनुमति है। includeनिर्देश के बाद प्रीप्रोसेसिंग टोकन सामान्य पाठ की तरह ही संसाधित होते हैं। (वर्तमान में प्रत्येक पहचानकर्ता को एक स्थूल नाम के रूप में परिभाषित किया गया है, इसकी जगह प्रीप्रोसेसिंग टोकन की सूची है।) सभी प्रतिस्थापनों के बाद का निर्देश दो पिछले रूपों में से एक से मेल खाएगा। वह विधि जिसके द्वारा ए <और >प्रीप्रोसेसिंग टोकन जोड़ी या "वर्णों के जोड़े के बीच प्रीप्रोसेसिंग टोकन का क्रम एकल हेडर नाम से जोड़ा जाता है प्रीप्रोसेसिंग टोकन कार्यान्वयन-परिभाषित है।

परिभाषाएं:

• h-char: स्रोत वर्ण का कोई भी सदस्य नई-लाइन वर्ण को छोड़कर सेट करता है और >

• q-char: स्रोत वर्ण का कोई भी सदस्य नई-लाइन वर्ण को छोड़कर सेट करता है और "

Comments

प्रासंगिक: जी ++ में कार्यान्वयन और दृश्य सी ++ में

— अलेक्जेंडर मालाखोव

@piCookie दोनों <filename> और "filename" कार्यान्वयन-परिभाषित स्थानों की खोज करते हैं। तो अंतर क्या है ?

— onmyway133

@Tefan, मैं सिर्फ उस मानक को उद्धृत कर रहा हूं जो INCLUDE_PATH के बारे में कुछ नहीं कहता है। आपका कार्यान्वयन ऐसा कर सकता है, और मेरा नहीं हो सकता है। मूल प्रश्न सामान्य रूप से C था और विशेष रूप से gcc (जो मुझे नहीं लगता कि INCLUDE_PATH का उपयोग करता है) या Microsoft C (जो मुझे लगता है कि) या कोई अन्य है, इसलिए इसका उत्तर मूल रूप से नहीं दिया जा सकता है, बल्कि इसके बजाय प्रत्येक कार्यान्वयन के दस्तावेज़ीकरण को संदर्भित किया जाना चाहिए।

— piCookie

इन सभी स्थितियों के साथ, ठोस उदाहरण (विशेष रूप से सामान्य परिदृश्य) बहुत उपयोगी और समान रूप से सराहे जाते हैं। अनावश्यक रूप से सामान्य प्रश्नों के अधिक से अधिक व्यावहारिक उपयोग के लिए उपयोग न करें।

— वार्गोनियन

"यहाँ बताया गया है कि C मानक कैसे

— क्रिया

Answer 3

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

यदि #include "file"प्रपत्र का उपयोग किया जाता है, तो कार्यान्वयन पहले दिए गए नाम की एक फ़ाइल की तलाश करता है, यदि समर्थित है। यदि नहीं (समर्थित), या यदि खोज विफल हो जाती है, तो कार्यान्वयन व्यवहार करता है जैसे कि अन्य ( #include <file>) फॉर्म का उपयोग किया गया था।

इसके अलावा, एक तीसरा रूप मौजूद है और इसका उपयोग तब किया जाता है जब #includeनिर्देश ऊपर के किसी भी रूप से मेल नहीं खाता है। इस रूप में, कुछ बुनियादी प्रीप्रोसेसिंग (जैसे मैक्रो विस्तार) #includeनिर्देश के "ऑपरेंड" पर किया जाता है , और परिणाम दो अन्य रूपों में से एक से मेल खाने की उम्मीद है।

Comments

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

— दान मोल्डिंग

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

— ऐब

मैं एक दशक से यह "मानक हेडर फ़ाइल फॉर्म में होना जरूरी नहीं" पढ़ रहा हूं। एक वास्तविक दुनिया उदाहरण प्रदान करने के लिए देखभाल?

— मैक्सिम Egorushkin

@ मैक्सिम येगोरुस्किन: मैं किसी भी मौजूदा वास्तविक दुनिया के उदाहरणों के बारे में नहीं सोच सकता; हालाँकि, कोई भी पूर्ण C11 कंपाइलर MS-DOS के लिए मौजूद नहीं हो सकता है जब तक हेडर के लिए फाइल नहीं होनी चाहिए। ऐसा इसलिए है क्योंकि C11 हेडर के कुछ नाम "8.3" MS-DOS फ़ाइल नाम सीमा के साथ संगत नहीं हैं।

— दान मोल्डिंग

@MaximEgorushkin: VAX / VMS C कंपाइलर ने सभी C रनटाइम लाइब्रेरी हेडर को एक सिंगल टेक्सचर लाइब्रेरी फाइल (एक यूनिक्स आर्काइव के समान) में रखा, और लाइब्रेरी में इंडेक्स करने के लिए कुंजी के बीच <और स्ट्रिंग का उपयोग किया >।

— एड्रियन मैकार्थी

Answer 4

यहाँ कुछ अच्छे उत्तर सी मानक के संदर्भ में हैं, लेकिन POSIX मानक को भूल गए, विशेष रूप से c99 (जैसे C संकलक) कमांड के विशिष्ट व्यवहार ।

के अनुसार ओपन समूह बेस विनिर्देशों अंक 7 ,

-मैं निर्देशिका

हेडर की खोज के लिए एल्गोरिथ्म को बदलें जिनके नाम सामान्य स्थानों में देखने से पहले डायरेक्टरी पाथनाम नाम की निर्देशिका में देखने के लिए पूर्ण पथनाम नहीं हैं। इस प्रकार, शीर्षलेख जिनके नाम डबल-कोट्स ("") में संलग्न हैं, उन्हें पहले फ़ाइल की निर्देशिका में #include लाइन के साथ खोजा जाएगा , फिर -I विकल्पों में नामित निर्देशिकाओं में , और सामान्य स्थानों पर अंतिम। हेडर जिनके नाम कोण कोष्ठक ("<>") में संलग्न हैं, हेडर केवल -I विकल्प में और फिर सामान्य स्थानों में नामित निर्देशिकाओं के लिए खोजा जाएगा । निर्दिष्ट किए गए क्रम में -I विकल्पों में नामित निर्देशिकाएं खोजी जाएंगी।c99 कमांड मंगलाचरण।

इसलिए, एक POSIX आज्ञाकारी वातावरण में, एक POSIX आज्ञाकारी C संकलक के साथ, #include "file.h"संभवतः ./file.hपहले की खोज करने जा रहा है , जहां .निर्देशिका है जहां #includeकथन के साथ फ़ाइल है , जबकि #include <file.h>, संभवतः /usr/include/file.hपहले के लिए खोज करने जा रहा है , जहां /usr/includeआपका सिस्टम परिभाषित है। हेडर के लिए सामान्य स्थान (यह POSIX द्वारा परिभाषित नहीं लगता है)।

Comments

पाठ का सटीक स्रोत क्या है? क्या यह IEEE Std 1003.1, 2013 के मानदंड से है?

— ऑक्सक्स

@osgx: वह शब्द (या कुछ इसी तरह का) POSIX विनिर्देशन में पाया जाता है c99- जो C कंपाइलर के लिए POSIX नाम है। (POSIX 2008 मानक शायद ही C11 को संदर्भित कर सकता है; POSIX 2008 के लिए 2013 के अपडेट ने C मानक को उसके द्वारा निर्दिष्ट किए गए परिवर्तन को नहीं बदला।)

— जोनाथन लेफ़लर

यह मेरा पहला विचार भी था। Gcc के लिए मैनपेज में अन्य लोग भी शामिल हैं। पुस्तकालयों के लिए भी एक समान बात है - -L।

— २१:५५ बजे प्रीफटन

Answer 5

GCC प्रलेखन का कहना है कि दोनों के बीच अंतर के बारे में निम्नलिखित हैं:

उपयोगकर्ता और सिस्टम हेडर दोनों फाइलें प्रीप्रोसेसिंग निर्देश का उपयोग करके शामिल हैं ‘#include’। इसके दो प्रकार हैं:

#include <file>

इस वैरिएंट का उपयोग सिस्टम हेडर फाइलों के लिए किया जाता है। यह सिस्टम निर्देशिकाओं की एक मानक सूची में एक फ़ाइल नामक फ़ाइल की खोज करता है। आप इस सूची में -Iविकल्प ( आमंत्रण देखें ) के साथ निर्देशिकाओं को प्रस्तुत कर सकते हैं ।

#include "file"

इस संस्करण का उपयोग आपके स्वयं के प्रोग्राम की हेडर फ़ाइलों के लिए किया जाता है। यह निर्देशिका में पहले फ़ाइल नाम फ़ाइल की खोज करता है जिसमें वर्तमान फ़ाइल होती है, फिर उद्धरण निर्देशिकाओं में और फिर उसी निर्देशिका के लिए उपयोग की जाती है <file>। आप -iquoteविकल्प के साथ निर्देशिकाओं की सूची के लिए निर्देशिकाओं को प्रस्तुत कर सकते हैं । का तर्क ‘#include’, चाहे उद्धरण चिह्नों या कोण कोष्ठक के साथ सीमांकित हो, एक स्ट्रिंग स्थिरांक की तरह व्यवहार करता है कि टिप्पणियों को मान्यता नहीं दी जाती है, और मैक्रो नामों का विस्तार नहीं किया जाता है। इस प्रकार, #include <x/*y>नामित एक सिस्टम हेडर फ़ाइल के समावेश को निर्दिष्ट करता है x/*y।

हालाँकि, यदि बैकस्लैश फ़ाइल के भीतर होते हैं, तो उन्हें साधारण पाठ वर्ण माना जाता है, वर्णों से बचकर नहीं। सी में स्ट्रिंग स्थिरांक के लिए उपयुक्त वर्ण भागने के अनुक्रमों में से कोई भी संसाधित नहीं है। इस प्रकार, #include "x\n\\y"एक फ़ाइल नाम निर्दिष्ट करता है जिसमें तीन बैकस्लैश होते हैं। (कुछ सिस्टम '\' की व्याख्या पथनाम विभाजक के रूप में करते हैं। ये सभी ‘/’समान तरीके से व्याख्या करते हैं। यह केवल उपयोग करने के लिए सबसे पोर्टेबल है ‘/’।)

यह एक त्रुटि है अगर फ़ाइल नाम के बाद लाइन पर कुछ भी (टिप्पणियों के अलावा) है।

Answer 6

ऐसा होता है:

"mypath/myfile" is short for ./mypath/myfile

साथ .या तो जहां फ़ाइल की निर्देशिका जा रहा है #includeमें निहित है, और / या संकलक की वर्तमान कार्यशील निर्देशिका, और / याdefault_include_paths

तथा

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

अगर ./अंदर है <default_include_paths>, तो इससे कोई फर्क नहीं पड़ता।

यदि mypath/myfileकोई अन्य शामिल निर्देशिका में है, तो व्यवहार अपरिभाषित है।

Comments

नहीं, के #include "mypath/myfile"बराबर नहीं है #include "./mypath/myfile"। जैसा कि piCookie का उत्तर कहता है, दोहरे उद्धरण संकलक को कार्यान्वयन-परिभाषित तरीके से खोजने के लिए कहते हैं - जिसमें निर्दिष्ट स्थानों में खोज शामिल है #include <...>। (वास्तव में, यह शायद बराबर है, लेकिन केवल इसलिए, उदाहरण के लिए, के /usr/include/mypath/myfileरूप में संदर्भित किया जा सकता है /usr/include/./mypath/myfile- कम से कम यूनिक्स जैसी प्रणालियों पर।)

— कीथ थॉम्पसन

@ कीथ थॉम्पसन: यह सही है, मैं अपने लिनक्स बॉक्स के बारे में सोच रहा था। जाहिर है यह अलग हो सकता है। हालांकि व्यवहार में, गैर-पॉज़िक्स ऑपरेटिंग सिस्टम के रूप में विंडोज इंटरप्रिट / पथ विभाजक के रूप में भी करता है, और / भी मौजूद है।

— स्टीफन स्टाइगर

-L dirpath विकल्प फिर dirpath को जोड़ता है defaultincludepaths, जैसा कि एक और अर्थ देने के विपरीत है .(जैसा कि ऊपर कहा गया है)। यह अपेक्षित परिणाम है कि दोनों #include "..."और dirpath#include <...> में खोज करते हैं

— प्रोटॉन्गुन

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

— कार्लो वुड

Answer 7

<file>शामिल में खोज करने के लिए पूर्वप्रक्रमक बताता -Iनिर्देशिका और पूर्वनिर्धारित निर्देशिका में पहले , तो ग फ़ाइल की निर्देशिका में। इसमें "file"स्रोत फ़ाइल की निर्देशिका को पहले खोजने के लिए प्रीप्रोसेसर को शामिल किया गया है , और फिर वापस -Iऔर पूर्वनिर्धारित किया गया है। सभी गंतव्यों को वैसे भी खोजा जाता है, केवल खोज का क्रम अलग होता है।

2011 का मानक ज्यादातर "16.2 स्रोत फ़ाइल समावेशन" में शामिल फ़ाइलों की चर्चा करता है।

2 फार्म का एक प्रीप्रोसेसिंग निर्देश

# include <h-char-sequence> new-line

हेडर के लिए निर्दिष्ट अनुक्रम द्वारा विशिष्ट रूप से पहचाने गए हेडर के लिए कार्यान्वयन-परिभाषित स्थानों के अनुक्रम की खोज करता है, और हेडर की संपूर्ण सामग्री द्वारा उस निर्देश के प्रतिस्थापन का कारण बनता है। स्थानों को कैसे निर्दिष्ट किया जाता है या पहचाने जाने वाले शीर्षलेख कार्यान्वयन-परिभाषित है।

3 फार्म का एक प्रीप्रोसेसिंग निर्देश

# include "q-char-sequence" new-line

"सीमांकक के बीच निर्दिष्ट अनुक्रम द्वारा पहचानी गई स्रोत फ़ाइल की संपूर्ण सामग्री द्वारा उस निर्देश के प्रतिस्थापन का कारण बनता है। नामित स्रोत फ़ाइल को कार्यान्वयन-परिभाषित तरीके से खोजा जाता है। यदि यह खोज समर्थित नहीं है, या यदि खोज विफल हो जाती है। निर्देश को पुन: प्रकाशित किया जाता है जैसे कि यह पढ़ा जाता है

# include <h-char-sequence> new-line

मूल निर्देश से समान समाहित अनुक्रम (> वर्ण, यदि कोई हो) के साथ।

ध्यान दें कि यदि फ़ाइल नहीं मिली है तो "xxx"फ़ॉर्म को संक्षिप्त करें <xxx>। बाकी कार्यान्वयन-परिभाषित है।

Comments

क्या आप इस बात का संदर्भ दे सकते हैं कि C मानक में यह -Iव्यवसाय कहां निर्दिष्ट है?

— जुआनकोपंजा

मैं कोई संदर्भ नहीं देखता हूं -I।

— जुआनकोपनज़ा

यह "कार्यान्वयन-परिभाषित" हिस्सा है।

Answer 8

#include <file.h>कम्पाइलर को इसके "हेडर" में हेडर की खोज करने के लिए कहता है, जैसे कि मिनगॉ के लिए कंपाइलर file.hC: \ MinGW \ में शामिल होगा या जहां भी आपका कंपाइलर स्थापित है, उसकी खोज करेंगे।

#include "file"संकलक को वर्तमान निर्देशिका (यानी वह निर्देशिका जिसमें स्रोत फ़ाइल रहती है) को खोजने के लिए कहता है file।

आप -Iयह बताने के लिए GCC के लिए ध्वज का उपयोग कर सकते हैं कि, जब यह एंगल्ड कोष्ठक के साथ सम्मिलित करता है, तो इसके बाद निर्देशिका में हेडर की भी खोज करनी चाहिए -I। जीसीसी झंडे के बाद निर्देशिका का इलाज करेगा जैसे कि वह includesनिर्देशिका थी।

उदाहरण के लिए, यदि आपके पास myheader.hअपनी निर्देशिका में एक फ़ाइल है , तो आप यह कह सकते हैं कि #include <myheader.h>क्या आपने ध्वज के साथ जीसीसी को कॉल किया था -I .(यह दर्शाता है कि उसे वर्तमान निर्देशिका में शामिल होना चाहिए।)

-Iध्वज के बिना , आपको #include "myheader.h"फ़ाइल को शामिल करने के लिए, या अपने संकलक myheader.hकी includeनिर्देशिका में स्थानांतरित करने के लिए उपयोग करना होगा ।

Answer 9

मानक द्वारा - हाँ, वे अलग हैं:

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include <h-char-sequence> new-line

  एक हैडर के बीच निर्दिष्ट अनुक्रम द्वारा विशिष्ट पहचान के लिए कार्यान्वयन से परिभाषित स्थानों में से एक दृश्य खोज <और >सीमांकक, और हेडर की संपूर्ण सामग्री द्वारा कि निर्देश के प्रतिस्थापन का कारण बनता है। स्थानों को कैसे निर्दिष्ट किया जाता है या हेडर की पहचान की गई है, कार्यान्वयन-परिभाषित है।

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include "q-char-sequence" new-line

  "सीमांकक के बीच निर्दिष्ट अनुक्रम द्वारा पहचानी गई स्रोत फ़ाइल की संपूर्ण सामग्री द्वारा उस निर्देश के प्रतिस्थापन का कारण बनता है। नामित स्रोत फ़ाइल को कार्यान्वयन-परिभाषित तरीके से खोजा जाता है। यदि यह खोज समर्थित नहीं है, या यदि खोज विफल हो जाती है, तो निर्देश पुन: मुद्रित किया जाता है जैसे कि यह पढ़ा जाता है

  #include <h-char-sequence> new-line

  >मूल निर्देश से समान निहित अनुक्रम ( वर्णों सहित , यदि कोई हो) के साथ।

• प्रपत्र का एक पूर्वप्रक्रमक निर्देश

  #include pp-tokens new-line

  (यह दो पिछले रूपों में से एक से मेल नहीं खाता) की अनुमति है। includeनिर्देश के बाद प्रीप्रोसेसिंग टोकन सामान्य पाठ की तरह ही संसाधित होते हैं। (वर्तमान में प्रत्येक पहचानकर्ता को एक स्थूल नाम के रूप में परिभाषित किया गया है, इसकी जगह प्रीप्रोसेसिंग टोकन की सूची है।) सभी प्रतिस्थापनों के बाद का निर्देश दो पिछले रूपों में से एक से मेल खाएगा। वह विधि जिसके द्वारा ए <और >प्रीप्रोसेसिंग टोकन जोड़ी या "वर्णों के जोड़े के बीच प्रीप्रोसेसिंग टोकन का क्रम एकल हेडर नाम से जोड़ा जाता है प्रीप्रोसेसिंग टोकन कार्यान्वयन-परिभाषित है।

परिभाषाएं:

• h-char: स्रोत वर्ण का कोई भी सदस्य नई-लाइन वर्ण को छोड़कर सेट करता है और >

• q-char: स्रोत वर्ण का कोई भी सदस्य नई-लाइन वर्ण को छोड़कर सेट करता है और "

ध्यान दें कि मानक कार्यान्वयन-परिभाषित शिष्टाचार के बीच कोई संबंध नहीं बताता है। पहला फ़ॉर्म एक कार्यान्वयन-परिभाषित तरीके से खोज करता है, और दूसरा एक (संभवतः अन्य) कार्यान्वयन-परिभाषित तरीके से। मानक यह भी निर्दिष्ट करता है कि कुछ शामिल फाइलें मौजूद होंगी (उदाहरण के लिए <stdio.h>)।

औपचारिक रूप से आपको अपने संकलक के लिए मैनुअल पढ़ना होगा, हालांकि सामान्य रूप से (परंपरा से) #include "..."प्रपत्र उस फ़ाइल की निर्देशिका को खोजता है जिसमें #includeपहले पाया गया था, और फिर निर्देशिका जो #include <...>प्रपत्र खोजती है (पथ शामिल करें, जैसे सिस्टम हेडर) )।

Comments

यह ज्यादातर सात साल पहले के piCookie के उत्तर के समान ही पाठ है ।

— काइल स्ट्रैंड

@KyleStrand ऐसा इसलिए है क्योंकि एक ही पाठ मानक में संबंधित अनुभाग का एक उद्धरण है - वह पाठ समान होना चाहिए। वास्तविक उत्तर एक ही पाठ नहीं है और कुछ अलग है - जबकि मैं यह भी मानता हूं कि इसे कार्यान्वयन के लिए दस्तावेज में लिखा जाएगा, मैं यह भी ध्यान देता हूं कि ये भी एक पारंपरिक तरीका है, जिसकी व्याख्या की जाती है (जो कि सबसे अधिक या सभी संकलक मैंने उपयोग किए हैं) ।

— बजे

IMO यह यहां सबसे अच्छा जवाब है, क्योंकि यह दोनों को कवर करता है कि मानक क्या कहता है और वास्तव में सबसे अधिक संकलक क्या करते हैं।

— 13

Answer 10

महान जवाब के लिए धन्यवाद, esp। एडम स्टेल्माज़्स्की और पिक्की, और ऐब।

कई प्रोग्रामर की तरह, मैंने "myApp.hpp"एप्लिकेशन विशिष्ट फ़ाइलों के लिए फ़ॉर्म का उपयोग करने के अनौपचारिक सम्मेलन का उपयोग किया है , और <libHeader.hpp>पुस्तकालय और कंपाइलर सिस्टम फ़ाइलों के लिए फ़ॉर्म, अर्थात ( /Iऔर INCLUDEपर्यावरण चर में निर्दिष्ट फ़ाइलों के लिए, जो मानक था) के लिए सोच रहा था।

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

#include "../../MyProgDir/SourceDir1/someFile.hpp"

MSVS के पुराने संस्करणों को डबल बैकस्लैश (\\) की आवश्यकता थी, लेकिन अब इसकी आवश्यकता नहीं है। मुझे नहीं पता कि यह कब बदल गया। बस 'निक्स' के साथ संगतता के लिए फॉरवर्ड स्लैश का उपयोग करें (विंडोज यह स्वीकार करेगा)।

यदि आप वास्तव में इसके बारे में चिंतित हैं, "./myHeader.h"तो स्रोत कोड के रूप में एक ही निर्देशिका में एक शामिल फ़ाइल के लिए उपयोग करें (मेरे वर्तमान, बहुत बड़ी परियोजना में कुछ डुप्लिकेट शामिल हैं फ़ाइल नाम बिखरे हुए हैं - वास्तव में एक कॉन्फ़िगरेशन प्रबंधन समस्या)।

यहाँ MSDN स्पष्टीकरण यहां आपकी सुविधा के लिए नकल की)।

उद्धृत रूप

प्रीप्रोसेसर इस क्रम में फ़ाइलों को शामिल करने के लिए खोज करता है:

1. उसी निर्देशिका में जिस फ़ाइल में #include स्टेटमेंट है।
2. वर्तमान में खोली गई निर्देशिकाओं में उल्टे क्रम में फाइलें शामिल हैं, जिसमें
   वे खोले गए थे। माता-पिता की निर्देशिका में खोज शुरू होती है जिसमें फ़ाइल शामिल होती है और
   किसी भी दादा-दादी की फाइलों में निर्देशिका के माध्यम से ऊपर की ओर जारी रहती है।
3. प्रत्येक /Iकंपाइलर विकल्प द्वारा निर्दिष्ट पथ के साथ ।
4. INCLUDEपर्यावरण चर द्वारा निर्दिष्ट पथों के साथ ।

कोण-कोष्ठक रूप

प्रीप्रोसेसर इस क्रम में फ़ाइलों को शामिल करने के लिए खोज करता है:

1. प्रत्येक /Iकंपाइलर विकल्प द्वारा निर्दिष्ट पथ के साथ ।
2. जब कमांड लाइन पर संकलन होता है, तो INCLUDEपर्यावरण चर द्वारा निर्दिष्ट पथों के साथ ।

Answer 11

कम से कम जीसीसी संस्करण <= 3.0 के लिए, कोण-ब्रैकेट फॉर्म में शामिल फ़ाइल और एक के बीच एक निर्भरता उत्पन्न नहीं होती है।

इसलिए यदि आप निर्भरता नियम (उदाहरण के लिए जीसीसी -एम विकल्प का उपयोग करके) उत्पन्न करना चाहते हैं, तो आपको उन फ़ाइलों के लिए उद्धृत प्रपत्र का उपयोग करना होगा जो निर्भरता के पेड़ में शामिल होने चाहिए।

( Http://gcc.gnu.org/onbuildocs/cpp/Invocation.html देखें )

Comments

हां - निर्भरता पैदा करने के कई अलग-अलग तरीके हैं। यह उनमें से एक है, लेकिन यह केवल एक ही नहीं है।

— प्रीतिफलन

Answer 12

के लिए #include ""एक संकलक सामान्य रूप से फ़ाइल जो जिसमें शामिल करें और फिर अन्य फ़ोल्डर के फ़ोल्डर खोज करता है। के लिए #include <>संकलक वर्तमान फ़ाइल का फ़ोल्डर खोज नहीं करता है।

Comments

यकीन नहीं होता कि लोग असहमत क्यों हैं।

— मैक्सिम इगोरुशिन

मुझे संदेह है कि ज्यादातर लोग अपने सीडब्ल्यूडी में केवल फाइलों को संकलित करते हैं। यदि आप डायरेक्टरी फू में हैं, और आप फू / यूनीटेस्ट / बार.का संकलन कर रहे हैं, और इसमें बार.ह शामिल है, तो "बार.एच" काम करता है और <बार.एच> नहीं करता है।

@ माक्सिम लोग असहमत हैं क्योंकि आपके द्वारा वर्णित व्यवहार मानक सी नहीं है

— ऑसविन जूल

@Spookbuster अधिकार, मानक दोनों कहते हैं <filename>और "filename"कार्यान्वयन-परिभाषित स्थानों की खोज करते हैं।

— मैक्सिम एगोरुस्किन

Answer 13

जब आप #include <filename> का उपयोग करते हैं, तो C- C ++ हेडर फ़ाइलों (stdio.h \ cstdio, string, वेक्टर, आदि) की निर्देशिका में फ़ाइल की तलाश में पूर्व-प्रोसेसर। लेकिन, जब आप #include "फ़ाइलनाम" का उपयोग करते हैं: पहला, वर्तमान-निर्देशिका में फ़ाइल की तलाश में पूर्व-प्रोसेसर, और यदि यह यहाँ नहीं है - तो वह C \ C ++ हेडर फ़ाइलों की निर्देशिका में खोज रहा है।

Comments

सालों से एक सही जवाब उपलब्ध होने के बाद, एक को क्यों प्रस्तुत करें, यह सिर्फ गलत तरीके से गलत है? भले ही आम है, #includeनिर्देश सख्ती से फ़ाइलों से संबंधित नहीं है।

— IInspectable

@IIspectable कृपया बताएं कि यह फाइलों से संबंधित क्यों नहीं है।

— बेहरोज करजु २६'१

Answer 14

कोण कोष्ठक के साथ एक #include "शामिल होने के लिए" सिस्टम हेडर "कहने का एक बहुत ही जटिल तरीका" (स्थानों का कार्यान्वयन-निर्भर सूची) खोजेगा।

उद्धरण के साथ एक #include बस एक फ़ाइल के लिए खोज करेगा (और, "एक कार्यान्वयन-निर्भर तरीके से", blh)। जिसका अर्थ है, सामान्य अंग्रेजी में, यह उस पथ / फ़ाइलनाम को लागू करने का प्रयास करेगा जिसे आप उस पर टॉस करते हैं और सिस्टम पथ को प्रीपेंड नहीं करेंगे या अन्यथा उसके साथ छेड़छाड़ करेंगे।

इसके अलावा, अगर #include "" विफल रहता है, तो इसे मानक के रूप में #include <> के रूप में फिर से पढ़ा जाता है।

जीसीसी प्रलेखन एक (संकलक विशिष्ट) वर्णन जो हालांकि जीसीसी के लिए विशिष्ट नहीं है और मानक जा रहा है, आईएसओ मानक के वकील शैली बात से समझने के लिए बहुत आसान है।

Comments

हालाँकि, कोण कोष्ठक या उद्धरण का उपयोग फ़ाइलों को शामिल करने के तरीके को प्रभावित नहीं करता है, यह बिल्कुल वैसा ही है: प्रीप्रोसेसर निबंधात्मक रूप से एक बड़े स्रोत फ़ाइल को copy'n'Paste करके बनाता है जिसमें कोड को मूल स्रोत फ़ाइल में फ़ाइलों को शामिल करने से पहले, देना चाहिए संकलक के लिए (पूर्वप्रक्रमक अन्य कार्य करता है, जैसे #define susteration, #if मूल्यांकन, लेकिन #include प्रसंस्करण इतना आसान है)

— Loghorn

संघर्षों के बारे में क्या? उदाहरण के लिए zlib.h, मेरे पास मेरे 'उपयोगकर्ता' खोज पथ हैं, और सिस्टम खोज पथ में एक भिन्न संस्करण मौजूद है, तो क्या #include <zlib.h>सिस्टम संस्करण #include "zlib.h"शामिल है और मेरा अपना शामिल है?

— the_mandrill

अहा, मेरे अपने सवाल का जवाब दिया: stackoverflow.com/questions/21593/…

— the_mandrill

यह मानने के लिए धन्यवाद कि मानक (ओं) और ठेठ कार्यान्वयन सम्मेलनों दोनों ही प्रासंगिक हैं, बजाय यह बताते हुए कि यह अनजानी है क्योंकि यह मानक द्वारा निर्दिष्ट नहीं है।

— काइल स्ट्रैंड

Answer 15

#include "filename" // User defined header
#include <filename> // Standard library header.

उदाहरण:

यहाँ फ़ाइल नाम है Seller.h:

#ifndef SELLER_H     // Header guard
#define SELLER_H     // Header guard

#include <string>
#include <iostream>
#include <iomanip>

class Seller
{
    private:
        char name[31];
        double sales_total;

    public:
        Seller();
        Seller(char[], double);
        char*getName();

#endif

वर्ग कार्यान्वयन में (उदाहरण के लिए, Seller.cppऔर अन्य फ़ाइलों में जो फ़ाइल का उपयोग करेगा Seller.h), उपयोगकर्ता द्वारा परिभाषित हेडर को अब शामिल किया जाना चाहिए, इस प्रकार है:

#include "Seller.h"

Answer 16

• #include <> पूर्वनिर्धारित हेडर फ़ाइलों के लिए है

यदि हेडर फ़ाइल पूर्वनिर्धारित है तो आप बस हेडर फ़ाइल नाम को कोणीय कोष्ठक में लिखेंगे, और यह इस तरह दिखेगा (मान लें कि हमारे पास पूर्वनिर्धारित हेडर फ़ाइल नाम iostream है):

#include <iostream>

• #include " " हैडर फ़ाइलों के लिए प्रोग्रामर परिभाषित करता है

यदि आप (प्रोग्रामर) ने अपनी खुद की हेडर फाइल लिखी है तो आप हेडर फाइल का नाम उद्धरणों में लिखेंगे। तो, मान लीजिए कि आपने हेडर फ़ाइल लिखी है myfile.h, तो यह एक उदाहरण है कि आप उस फाइल को शामिल करने के लिए निर्देश को कैसे शामिल करेंगे:

#include "myfile.h"

Comments

इसका पूर्व-निर्धारित हेडर फाइलों से कोई लेना-देना नहीं है। यह खोज के लिए स्थानों के साथ करना है।

— सी जॉनसन

Answer 17

यहाँ कई उत्तर फाइल को खोजने के लिए कंपाइलर खोजे जाने वाले रास्तों पर ध्यान केंद्रित करेंगे। हालांकि यह वही है जो अधिकांश कंपाइलर करते हैं, एक अनुरूप कंपाइलर को मानक हेडर के प्रभावों के साथ प्रीप्रोग्राम करने की अनुमति दी जाती है, और #include <list>एक स्विच के रूप में इलाज करने, कहने के लिए, और यह एक फ़ाइल के रूप में मौजूद नहीं है।

यह विशुद्ध रूप से काल्पनिक नहीं है। कम से कम एक कंपाइलर है जो उस तरह से काम करता है। #include <xxx>केवल मानक हेडर के साथ उपयोग करने की सिफारिश की जाती है।

Answer 18

#include <abc.h>

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

#include "xyz.h"

कंपाइलर को उपयोगकर्ता-परिभाषित हेडर फ़ाइलों को शामिल करने के लिए बताएगा। तो कंपाइलर इन हेडर फ़ाइलों की वर्तमान फ़ोल्डर या -Iपरिभाषित फ़ोल्डरों में जाँच करेगा ।

Answer 19

C ++ में, दो तरीकों से एक फ़ाइल शामिल करें:

पहले वाला #include है जो पूर्वनिर्धारित डिफ़ॉल्ट स्थान में फ़ाइल को देखने के लिए प्रीप्रोसेसर को बताता है। यह स्थान अक्सर एक INCLUDE वातावरण चर है जो फ़ाइलों को शामिल करने के लिए पथ को दर्शाता है।

और दूसरा प्रकार #include "फ़ाइलनाम" है जो पूर्ववर्ती निर्देशिका में फ़ाइल के लिए पहले देखने के लिए प्रीप्रोसेसर को बताता है, फिर इसे उन पूर्वनिर्धारित स्थानों में खोजें जिन्हें उपयोगकर्ता ने सेट किया है।

Answer 20

फॉर्म 1 - #include <xxx>

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

फॉर्म 2 - #include "xxx"

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

---

सटीक खोज निर्देशिका सूची लक्ष्य प्रणाली पर निर्भर करती है कि जीसीसी कैसे कॉन्फ़िगर किया गया है और यह कहां स्थापित है। आप अपने जीसीसी संकलक की खोज निर्देशिका सूची को -v विकल्प के साथ चलाकर पा सकते हैं।

आप खोज मार्ग में अतिरिक्त निर्देशिकाओं को जोड़ सकते हैं - I dir , जिसके कारण dir को वर्तमान निर्देशिका (निर्देश के उद्धरण प्रपत्र के लिए) और मानक सिस्टम निर्देशिकाओं के आगे खोजा जा सकता है।

---

मूल रूप से, "xxx" वर्तमान निर्देशिका में खोज के अलावा कुछ भी नहीं है; अगर पर्चा वापस नहीं मिला

Comments

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

— जोनाथन लेफ़लर

@ जोनाथन लेफ़लर क्या आप मुझे "अच्छी तरह से स्थापित" उत्तर की ओर इशारा कर सकते हैं जो आपको लगता है कि दर्शन के उत्तर के समान संक्षिप्त और सटीक है?

— व्यक्तिगत_क्लाउड

#include "header.h"फॉर्म का विवरण सटीक नहीं है, @personal_cloud। मैं piCookie और Yann Droneaud के उत्तर को सबसे अधिक प्रासंगिक मानता हूं क्योंकि वे पहचानते हैं कि उनकी जानकारी कहां से आती है। मुझे शीर्ष-मतदान का उत्तर पूरी तरह से संतोषजनक नहीं लगता।

— जोनाथन लेफलर

यह उत्तर शीर्ष पर क्यों दिखाया गया है, जबकि दो उत्तर आगे नीचे 650+ वोट हैं? इस उत्तर ने मुझे भ्रमित कर दिया, क्योंकि यह मेरे द्वारा देखे गए व्यवहार से मेल नहीं खाता है। यह हो सकता है, क्योंकि कोण कोष्ठक से बचने नहीं करने के कारण अंतिम वाक्य टूट गया है। मुझे यकीन नहीं है कि इसका क्या मतलब है।

— नियॉनिट

Answer 21

#include <filename>जब एक सिस्टम फ़ाइल करने के लिए भेजा जा रहा है प्रयोग किया जाता है। यह एक हेडर फाइल है जिसे सिस्टम डिफॉल्ट स्थानों जैसे /usr/includeया पर पाया जा सकता है /usr/local/include। अपनी खुद की फ़ाइलों के लिए जिन्हें आपको किसी अन्य प्रोग्राम में शामिल करना होगा, आपको #include "filename"सिंटैक्स का उपयोग करना होगा ।

Answer 22

"सी फ़ाइल नाम>" मानक सी लाइब्रेरी स्थानों में खोज करता है

जबकि "फ़ाइल नाम" वर्तमान निर्देशिका में भी खोज करता है।

आदर्श रूप से, आप मानक सी पुस्तकालयों के लिए <...> का उपयोग करेंगे और उन पुस्तकालयों के लिए "..." जो आप लिखते हैं और वर्तमान निर्देशिका में मौजूद हैं।

Comments

कौन सी नई जानकारी इस उत्तर को अन्य लोगों के साथ जोड़ती है?

— डैनियल लैंगर

Answer 23

साधारण सामान्य नियम है कि कंपाइलर के साथ आने वाली हेडर फ़ाइलों को शामिल करने के लिए एंगल्ड कोष्ठक का उपयोग किया जाता है। किसी भी अन्य हेडर फ़ाइलों को शामिल करने के लिए दोहरे उद्धरण चिह्नों का उपयोग करें। अधिकांश संकलक इसे इस तरह से करते हैं।

1.9 - हेडर फाइलें प्री-प्रोसेसर निर्देशों के बारे में अधिक विस्तार से बताती हैं। यदि आप एक नौसिखिए प्रोग्रामर हैं, तो उस पृष्ठ को आपको वह सब समझने में मदद करनी चाहिए। मैंने इसे यहां से सीखा है, और मैं काम पर इसका पालन कर रहा हूं।

Answer 24

#include <filename>

का उपयोग तब किया जाता है जब आप C / C ++ सिस्टम या कंपाइलर लाइब्रेरी की हेडर फ़ाइल का उपयोग करना चाहते हैं। ये पुस्तकालय stdio.h, string.h, math.h, आदि हो सकते हैं।

#include "path-to-file/filename"

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

प्रीप्रोसेसर और हेडर के बारे में अधिक जानकारी के लिए। पढ़ें सी - प्रीप्रोसेसर ।

Answer 25

#include <filename>

• पूर्वप्रक्रमक कार्यान्वयन-निर्भर तरीके से खोज करता है। यह कंपाइलर को डायरेक्ट्री सर्च करने के लिए कहता है जहां सिस्टम हेडर फाइल होती हैं।
• यह विधि आमतौर पर मानक हेडर फ़ाइलों को खोजने के लिए उपयोग करती है।

#include "filename"

• यह कंपाइलर को हेडर फ़ाइलों को खोजने के लिए बताता है जहाँ प्रोग्राम चल रहा है। यदि यह विफल हो गया था, तो यह #include <filename>उस हेडर फ़ाइल की तरह व्यवहार करता है और खोज करता है जहाँ सिस्टम हेडर फ़ाइलें संग्रहीत होती हैं।
• यह विधि आमतौर पर उपयोगकर्ता परिभाषित हेडर फ़ाइलों (हेडर फाइलें जो उपयोगकर्ता द्वारा बनाई गई हैं) की पहचान के लिए उपयोग की जाती है। यदि आप मानक पुस्तकालय को कॉल करना चाहते हैं तो इसका उपयोग न करें क्योंकि इससे अधिक संकलन समय लगता है #include <filename>।

Answer 26

वर्तमान कॉन्फ़िगरेशन के आधार पर, gcc का उपयोग करके अपने सिस्टम पर खोज क्रम को देखने के लिए, आप निम्न कमांड निष्पादित कर सकते हैं। आप इस आदेश पर अधिक विवरण यहां पा सकते हैं

cpp -v /dev/null -o /dev/null

Apple LLVM संस्करण 10.0.0 (क्लैंग -1000.10.44.2)
लक्ष्य: x86_64-apple-darwin18.0.0
थ्रेड मॉडल: posix InstalledDir: Library / Developer / CommandLineTools / usr / bin
"" / लाइब्रेरी / डेवलपर / कमांडलाइनटूल / usr / bin / clang -cc1 -triple x86_64-apple-macosx10.14.0 -Wepepccated-objc-isa-use -Werror = deprecated-objc-isa-use -disable-free अक्षम-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-सख्त-वापसी-मैस्म-वर्बोज़ - munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning = lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 - isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -I / usr / local / इसमें -fdebug-compilation-dir / Users / hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1-रक्षक -fencode- विस्तारित-ब्लॉक-हस्ताक्षर -fobjc-runtime = macosx-10.14।0 -fmax-type-align = 16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -xc / dev / null
clang -cc1 संस्करण 10.0.0 (clang-1000.10.44.2) डिफ़ॉल्ट लक्ष्य x86_64-apple-darwin18.0.0 कोई भी अयोग्य निर्देशिका की अनदेखी नहीं कर रहा है "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include" निरंतर स्रोत की अनदेखी। निर्देशिका "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." खोज यहां प्रारंभ होती है:
#incroe <...> खोज यहां प्रारंभ होती है:
/ usr / local / शामिल
/ लाइब्रेरी / डेवलपर / CommandLineTools / usr / lib / बजना / 10.0.0 / शामिल
/ Library / डेवलपर / CommandLineTools / usr / शामिल
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/ Library / डेवलपर / CommandLineTools / SDKs / MacOSX10.14.sdk / सिस्टम / लाइब्रेरी / फ्रेमवर्क (फ्रेमवर्क निर्देशिका)
खोज सूची का अंत।

Answer 27

#include <file> 

एक फ़ाइल शामिल है जहाँ डिफ़ॉल्ट शामिल निर्देशिका है।

#include "file" 

वर्तमान निर्देशिका में एक फ़ाइल शामिल है जिसमें इसे संकलित किया गया था।

Answer 28

#Include statement लिखने के दो तरीके मौजूद हैं। ये हैं:

#include"filename"
#include<filename>

प्रत्येक रूप का अर्थ है

#include"mylib.h"

यह कमांड mylib.hवर्तमान निर्देशिका में फ़ाइल के लिए और साथ ही निर्देशिका की निर्दिष्ट सूची के रूप में एन खोजे जाने वाले खोज पथ को शामिल करेगा।

#include<mylib.h>

यह कमांड mylib.hकेवल निर्देशिका की निर्दिष्ट सूची में फ़ाइल की तलाश करेगी ।

खोज में शामिल पथ कुछ भी नहीं है, लेकिन निर्देशिकाओं की एक सूची है जो फ़ाइल के लिए खोज की जाएगी। अलग-अलग सी संकलक आपको अलग-अलग शिष्टाचार में खोज पथ सेट करने देते हैं।

Comments

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

— जोनाथन लेफलर