<string.h> अपने स्वयं के स्ट्रिंग के साथ विवादित।

Question

मेरे पास एक प्रोजेक्ट है जो g ++ (मैं अभी संस्करण नहीं देख सकता) के भीतर ठीक संकलित कर रहा था और अब यह xCode पर नहीं है।
मुझे लगता है कि मुझे अब समस्या मिली है ... मेरे पास मेरी प्रोजेक्ट में एक स्ट्रिंग.h फ़ाइल है और ऐसा लगता है कि एक्सकोड कंपाइलर (वह जीसीसी है) < cstring> से अपनी स्वयं की स्ट्रिंग फ़ाइल जोड़ने की कोशिश कर रहा है। । मैं इसके बारे में यकीन नहीं है, लेकिन क्या यह की तरह लग रहा से इस तस्वीर
http://www.jode.com.br/Joe/xCode1.png

पर एक नज़र डालें, तो यह प्रणाली फ़ाइल के बजाय अपने खुद के शामिल है, मैं सोच रहा था ... # शामिल नहीं करना चाहिए < फ़ाइल> एक सिस्टम शामिल हैं? <> की वजह से? और क्या सिस्टम में अपने फ़ाइल के भीतर एक फाइल शामिल नहीं होनी चाहिए, न कि मेरे आवेदन का मूल पथ?
जैसा कि मैंने कहा, मुझे यकीन नहीं है कि यह क्या हो रहा है क्योंकि मैं बस पिछले 2 दिनों में ओएसएक्स में माइग्रेट कर रहा हूं ...
मैं अपनी कक्षा और फ़ाइल नाम को संघर्ष के लिए बदलने वाला नहीं था, इसलिए यह काम करेगा, अगर यह वास्तव में समस्या है, लेकिन मैं सोच रहा था, ऐसा करने का एक और तरीका होना चाहिए, क्योंकि अब मेरी परियोजना इतनी बड़ी नहीं है कि मैं इसे कुछ समय में कर सकता हूं, लेकिन अगर परियोजना बड़ी थी तो क्या होगा? यह सब भी शामिल है और वर्ग के नाम को बदलने के लिए dificult होगा ...

किसी भी मदद की सराहना की

धन्यवाद,
जोनाथन

Answer 1

स्ट्रिंग की तरह मानक हेडर के रूप में एक ही नाम के साथ अपने हेडर नामकरण।एच और उनमें से #include <String.h> के साथ भी परेशानी की मांग कर रहा है (आवरण में अंतर कुछ प्लेटफॉर्म पर कोई फर्क नहीं पड़ता)।

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

#include <Jonathan/String.h> 

अब आप कि क्या बारे में चिंता करने की जरूरत नहीं है String.h फ़ाइल नाम उस पुस्तकालयों में से कुछ के साथ संघर्ष करता है जिसका उपयोग आप तब तक कर रहे हैं जब तक कि <Jonathan/String.h> भी शामिल न हो, जो असंभव है। सभी सभ्य तृतीय-पक्ष पुस्तकालय भी ऐसा करते हैं। उदाहरण के लिए, हम <function.hpp> को बढ़ावा में शामिल नहीं करते हैं, लेकिन इसके बजाय <boost/function.hpp> शामिल हैं। जीएलएच के बजाए जीएल/जीएलएच के साथ ही। यह अभ्यास अधिकांश भाग के लिए संघर्ष से बचाता है और आपको Text.h की तरह कुछ स्ट्रिंग.h का नाम बदलकर समस्याओं के आसपास काम करने की आवश्यकता नहीं है।

Answer 2

पर OSX फाइल सिस्टम असंवेदनशील मामला है - तो string.h आप हवा कर सकते हैं इस तरह के संघर्ष के साथ। String.h == string.h

Answer 3

हाँ, यदि आप

#include "file" 

का उपयोग स्थानीय निर्देशिका पहले देखा और

#include <file> 

केवल प्रणाली शामिल फ़ोल्डरों देखा जाता है।

पहले मामले में पहले पर ध्यान दें। इसका अर्थ यह है कि हर बार आपके स्थानीय संस्करण को कभी भी नहीं पहुंचाया जाना चाहिए (जब तक कि आपने INLUDE निर्देश के भीतर अपना स्रोत पथ शामिल नहीं किया हो)।

ने कहा कि, मेरे डमी सुझाव एक स्पष्ट नाम के साथ अपने स्थानीय फ़ाइल का नाम बदलने के लिए ...

Answer 4

यह string.h से नाम बदलने के

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

धन्यवाद अब तक,
जोनाथन

Answer 5

दो बातें आप में चला रहे हैं:

1. जैसा कि ऊपर बताया, मैक ओएस पर फाइल सिस्टम केस-संवेदी जब तक आप विशेष रूप से अपने फाइल सिस्टम केस-संवेदी होने के लिए की स्थापना की है।
2. जीसीसी स्थानीय और सिस्टम शीर्षलेख के बीच बहुत कुछ अंतर नहीं करता है पथ शामिल हैं। जब आप पथ के माध्यम से पथ में जोड़े जाने के लिए एक निर्देशिका निर्दिष्ट करते हैं, तो उस निर्देशिका का उपयोग स्थानीय और सिस्टम दोनों को ढूंढने के लिए किया जाएगा। केवल तभी जब आप -iquote का उपयोग करते हैं- I- निर्देशिका को ढूंढने के लिए एक निर्देशिका छोड़ दी जाती है। इसके अलावा, कंपाइलर के खोज पथ पर बिल्टिन "सिस्टम शामिल" निर्देशिकाएं हमेशा स्थानीय खोज की गई हैं।
   • ध्यान दें कि वर्तमान निर्देशिका स्थानीय के लिए उपयोग की जाती है लेकिन सिस्टम में शामिल नहीं है। इस मामले में, मेरा मानना ​​है कि यह स्ट्रिंग.h उठा रहा है क्योंकि प्रोजेक्ट सेटिंग्स स्पष्ट रूप से पथ को शामिल करने के लिए शीर्ष-स्तरीय प्रोजेक्ट निर्देशिका जोड़ती हैं।

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

#include "Josk/String.h" 

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

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

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

Answer 6

मुझे एक ही समस्या थी और इसे हल करना मुश्किल था। ठीक करने/खोजने के लिए मेरे घंटे लग गए। समस्या xcode का हेडर्मैप है।और समाधान - आरक्षित नामों में से उन तरह है, जो सामान्य रूप में एक अच्छा विचार है, लेकिन हमेशा तीसरे पक्ष के libs के साथ संभव नहीं बचने के अलावा - अपने उपयोगकर्ता परिभाषित सेटिंग्स को

USE_HEADERMAP = NO 

जोड़ना है।

इन लोगों के लिए प्रशंसा: http://meidell.dk/archives/2010/05/08/xcode-header-map-files/ http://www.cocoabuilder.com/archive/xcode/262586-header-file-problem-sorry-to-bug-this-list.html