सवाल #Include और #include "फ़ाइल नाम" के बीच क्या अंतर है?


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

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

1813
2017-08-22 01:40


मूल


gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC6 - legends2k
जीसीसी अपनी हैडर फ़ाइलों को कहां ढूंढता है - theoretisch


जवाब:


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

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

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

जीसीसी में एक और पूरा विवरण उपलब्ध है खोज पथ पर दस्तावेज़ीकरण


1046
2017-08-22 01:40



बयान: "प्रीप्रोसेसर एक ही निर्देशिका में खोज करता है ..." अभ्यास में सच हो सकता है लेकिन मानक कहता है कि नामित स्रोत फ़ाइल "कार्यान्वयन-परिभाषित तरीके से खोजी गई है"। पिकुकी से जवाब देखें। - Richard Corden
जबकि आपका उत्तर "सत्य" प्रतीत होता है, क्योंकि यह है कि सम्मेलन द्वारा कितने कार्यान्वयन कार्य करते हैं, आपको एब और पिकुकी के उत्तरों पर नज़र डालना चाहिए। वे दोनों इंगित करते हैं (सी मानक के शब्द से समर्थित) कि असली भेद "स्रोत फ़ाइल" (और नहीं, इसका मतलब यह नहीं है ".h" बनाम "के विपरीत" हेडर "शामिल है। सी")। इस संदर्भ में "स्रोत फ़ाइल" एक ".h" फ़ाइल हो सकती है (और आमतौर पर, और लगभग हमेशा होना चाहिए)। एक शीर्षलेख को फ़ाइल होने की आवश्यकता नहीं होती है (एक कंपाइलर उदाहरण के लिए एक हेडर शामिल कर सकता है जो स्थिर रूप से कोडित है, फाइल में नहीं)। - Dan Moulding
"... प्रीप्रोसेसर उसी निर्देशिका में खोज करता है क्योंकि फाइल को फ़ाइल के लिए संकलित किया जा रहा है।" यह कथन पूरी तरह से सही नहीं है। मुझे इस सवाल में दिलचस्पी थी क्योंकि मैं उत्सुक था कि वास्तविक उत्तर क्या है, लेकिन मुझे पता है कि यह सच नहीं है क्योंकि कम से कम जब आप अतिरिक्त निर्दिष्ट करते हैं तो जीसीसी के साथ पथ शामिल होता है- I जो #include "फ़ाइल नाम के साथ निर्दिष्ट फ़ाइलों की खोज करेगा। ज " - Gabriel Southern
जो लोग उत्तर पसंद नहीं करते हैं, कृपया एक व्यावहारिक उदाहरण दें, जहां यह गलत है। - 0kcats
निश्चित रूप से, मैंने हाल ही में इन वाक्यविन्यासों को मिश्रित किया जब हेडर को 'समान' लाइब्रेरी से शामिल किया गया और फिर से परिभाषा त्रुटियों के साथ समाप्त हो गया। अगर मे ठीक समझता हूँ, #include <...> सिस्टम पर स्थापित पैकेज का इस्तेमाल किया और #include "..." पास के भंडार संस्करण का इस्तेमाल किया। मैं उन पीछे की ओर हो सकता है। किसी भी तरह से, पैक किए गए हेडर में गार्ड शामिल है अंडरस्कोर के साथ prefixed है। (यह पैकेजों के लिए एक सम्मेलन हो सकता है या शायद जानबूझकर दोनों को मिश्रण करने से रोकने का एक तरीका हो सकता है, हालांकि संस्करण क्वालीफायर मुझे अधिक समझेंगे।) - John P


जानने का एकमात्र तरीका है अपने कार्यान्वयन के दस्तावेज को पढ़ना।

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

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

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

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

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

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

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

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

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

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

    #include pp-tokens new-line
    

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

परिभाषाएं:

  • एच-char: नए-पंक्ति चरित्र को छोड़कर स्रोत चरित्र सेट के किसी भी सदस्य और >

  • क्यू-चार: नए-पंक्ति चरित्र को छोड़कर स्रोत चरित्र सेट के किसी भी सदस्य और "


594
2017-09-16 21:06



प्रासंगिक: कार्यान्वयन जी ++ और में दृश्य सी ++ - Alexander Malakhov
कार्यान्वयन-परिभाषित स्थानों के लिए @piCookie दोनों <filename> और "filename" खोज। तो अंतर क्या है ? - onmyway133
@Stefan, मैं सिर्फ मानक उद्धृत कर रहा हूं जो INCLUDE_PATH के बारे में कुछ भी नहीं कहता है। आपका कार्यान्वयन ऐसा कर सकता है, और मेरा नहीं हो सकता है। मूल प्रश्न सामान्य रूप से सी था और विशेष रूप से जीसीसी (जो मुझे लगता है कि INCLUDE_PATH का उपयोग नहीं करता) या माइक्रोसॉफ्ट सी (जो मुझे लगता है) या किसी अन्य का उपयोग नहीं करता है, इसलिए इसे सामान्य रूप से उत्तर नहीं दिया जा सकता है बल्कि इसके बजाय प्रत्येक कार्यान्वयन के दस्तावेज़ीकरण का संदर्भ लिया जाना चाहिए। - piCookie
इन सभी परिस्थितियों के साथ, ठोस उदाहरण (विशेष रूप से सामान्य परिदृश्यों) बहुत उपयोगी और समान रूप से सराहना करते हैं। अनिवार्य रूप से सामान्य उत्तरों को प्राप्त करने के लिए उतना व्यावहारिक उपयोग नहीं है। - vargonian
"यहां बताया गया है कि सी मानक वर्बोज़ कैसे हो सकता है और आपके प्रश्न का उत्तर नहीं दे सकता" - anatolyg


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

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

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


215
2017-09-08 17:43



+1, यह शायद यहां सबसे संक्षिप्त और सही उत्तर है। मानक के अनुसार (जो piCookie उनके जवाब में उद्धरण), केवल एक ही असली अंतर "हेडर" बनाम "स्रोत फ़ाइल" है। खोज तंत्र कार्यान्वयन-किसी भी तरह से परिभाषित किया गया है। डबल कोट्स का उपयोग करने का अर्थ है कि आप "स्रोत फ़ाइल" को शामिल करना चाहते हैं, जबकि कोण ब्रैकेट का मतलब है कि आप "हेडर" शामिल करना चाहते हैं, जैसा कि आप कहते हैं, एक फ़ाइल नहीं हो सकती है। - Dan Moulding
खोज 4 9 के जवाब में डैन मोल्डिंग की टिप्पणी देखें; मानक हेडर को फ़ाइल फॉर्म में होना जरूरी नहीं है, इन्हें अंतर्निहित किया जा सकता है। - aib
मैं एक दशक के लिए यह "मानक शीर्षलेख फाइल फॉर्म में होना जरूरी नहीं है" पढ़ रहा हूं। असली दुनिया का उदाहरण प्रदान करने की देखभाल? - Maxim Egorushkin
@ मैक्सिम येगोरुस्किन: मैं किसी मौजूदा वास्तविक दुनिया के उदाहरणों के बारे में भी नहीं सोच सकता; हालांकि, एमएस-डॉस के लिए कोई पूरा सी 11 कंपाइलर मौजूद नहीं हो सकता है जब तक कि हेडर को फाइलें न हों। ऐसा इसलिए है क्योंकि सी 11 हेडर नामों में से कुछ "8.3" एमएस-डॉस फ़ाइल नाम सीमा के साथ संगत नहीं हैं। - Dan Moulding
@ मैक्सिम एगोरुस्किन: वीएक्स / वीएमएस सी कंपाइलर ने सभी सी रनटाइम लाइब्रेरी हेडर को एक एकल पाठ्य पुस्तकालय फ़ाइल (एक यूनिक्स संग्रह के समान) में रखा, और स्ट्रिंग का उपयोग किया < तथा >पुस्तकालय में सूचकांक की कुंजी के रूप में। - Adrian McCarthy


यहां कुछ अच्छे उत्तर सी मानक के संदर्भ बनाते हैं लेकिन पीओएसईक्स मानक भूल गए हैं, खासकर विशिष्ट व्यवहार सी 99 (उदाहरण के लिए सी कंपाइलर) आदेश।

इसके अनुसार ओपन ग्रुप बेस निर्दिष्टीकरण अंक 7,

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

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

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


92
2017-07-20 09:29



पाठ का सटीक स्रोत क्या है? क्या यह आईईईई स्टडी 1003.1, 2013 के मानक भाग से है? - osgx
@osgx: उस शब्द (या कुछ बेहद समान) के लिए POSIX विनिर्देश में पाया जाता है c99 - सी संकलक के लिए POSIX नाम कौन सा है। (POSIX 2008 मानक शायद ही कभी C11 का संदर्भ ले सकता है; 2013 के पॉज़िक्स 2008 के अपडेट ने सी मानक को नहीं बदला है जिसे संदर्भित किया गया है।) - Jonathan Leffler


ऐसा होता है:

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

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

तथा

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

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

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


36
2018-02-08 11:45



नहीं, #include "mypath/myfile" के बराबर नहीं है #include "./mypath/myfile"। चूंकि पिकुकी का जवाब कहता है, डबल कोट्स कंपाइलर को कार्यान्वयन-परिभाषित तरीके से खोजने के लिए कहते हैं - जिसमें निर्दिष्ट स्थानों में खोज शामिल है #include <...>। (वास्तव में, यह शायद समतुल्य है, लेकिन केवल इसलिए, उदाहरण के लिए, /usr/include/mypath/myfile के रूप में संदर्भित किया जा सकता है /usr/include/./mypath/myfile - कम से कम यूनिक्स जैसी प्रणालियों पर।) - Keith Thompson
@ किथ थॉम्पसन: यह सही है, मैं अपने लिनक्स बॉक्स के बारे में सोच रहा था। जाहिर है यह अलग हो सकता है। हालांकि अभ्यास में, विंडोज़ गैर-पॉज़िक्स ऑपरेटिंग सिस्टम के रूप में भी व्याख्याता / पथ विभाजक के रूप में करता है, और ./ भी मौजूद है। - Stefan Steiger
एलएल dirpath विकल्प तो जोड़ता है dirpath को defaultincludepaths, के रूप में एक और अर्थ देने के विरोध में . (जैसा ऊपर बताया गया है)। इसका अनुमान है कि दोनों #include "..." तथा #include <...> की खोज में dirpath - Protongun
मुझे लगता है कि यह उत्तर गलत है, क्योंकि इसका तात्पर्य है कि डबल कोट्स के साथ शामिल शीर्षलेख हमेशा मौजूदा कार्यशील निर्देशिका में देखे जाते हैं। खोज तंत्र रास्ता अधिक विस्तृत है; यह जवाब अपूर्ण है। मैं इस टिप्पणी को शिकायत या चमकने के लिए नहीं जोड़ रहा हूं, लेकिन क्योंकि सिस्टम मुझे यह बताने के लिए एक टिप्पणी जोड़ने के लिए कहता है कि मैंने यह जवाब क्यों दिया। - Carlo Wood


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

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

#include <file>

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

#include "file"

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

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

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


30
2018-01-14 04:52





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

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

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

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

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

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

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

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

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

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

ध्यान दें कि "xxx" फार्म घटता है <xxx> फॉर्म अगर फ़ाइल नहीं मिली है। शेष कार्यान्वयन-परिभाषित है।


23
2017-09-03 12:17



क्या आप सी मानक में कहां संदर्भ दे सकते हैं -I व्यापार निर्दिष्ट है? - juanchopanza
@juanchopanza किया। शीर्ष जवाब भी देखें :) - Arkadiy
मुझे कोई संदर्भ नहीं दिख रहा है -I। - juanchopanza
यह "कार्यान्वयन-परिभाषित" भाग है। - Arkadiy
आह। मैं आपका जवाब देता हूं, आप इसे ध्वनि बनाते हैं जैसे कि भाषा में कुछ निर्दिष्ट है। - juanchopanza


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

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

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

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

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

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

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

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

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

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

    #include pp-tokens new-line
    

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

परिभाषाएं:

  • एच-char: नए-पंक्ति चरित्र को छोड़कर स्रोत चरित्र सेट के किसी भी सदस्य और >

  • क्यू-चार: नए-पंक्ति चरित्र को छोड़कर स्रोत चरित्र सेट के किसी भी सदस्य और "

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

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


16
2017-08-18 06:21



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


महान उत्तरों के लिए धन्यवाद, esp। एडम Stelmaszczyk और piCookie, और एआईबी।

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

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

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

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

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

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

उद्धृत रूप

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

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

कोण-ब्रैकेट फॉर्म

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

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

12
2017-10-14 23:51





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

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

(देख http://gcc.gnu.org/onlinedocs/cpp/Invocation.html )


11
2017-10-25 12:35