<string.h>, конфликтующий с моим собственным String.h
У меня есть проект, который компилировал хорошо в g ++ (я не вижу версии прямо сейчас), и теперь на XCode это не. от какого это похоже, это включает мое собственное вместо системного файла, я задавался вопросом... не был должен, #include <файл> быть системой включают? из-за <>? и разве система не должна включать файл в своем собственном пути и не первоначальном тракте моего приложения? Любая справка ценится Спасибо,
Я думаю, что получил проблему теперь... У меня есть файл String.h в моем проекте, и это кажется tha компилятор XCode (который является gcc), пытается добавить мой собственный строковый файл от
http://www.jode.com.br/Joe/xCode1.png
Как я сказал, я не уверен, является ли это тем, какой случай, потому что я просто перемещаю в osx эти прошедшие 2 дня...
Я собирался изменить свое имя класса и имя файла для не конфликта, таким образом, оно будет работать, если это будет действительно проблемой, но я задавался вопросом, должен быть другой способ сделать это, потому что теперь мой проект не является настолько большим, таким образом, я могу сделать это в некоторое время, но что, если проект был больше? было бы трудно измениться, все включает и имена классов...
Jonathan
5 ответов
Если присвоить вашим заголовкам то же имя, что и стандартные заголовки, например string.h , и включить их просто с помощью #include , возникнут проблемы (разница в регистре не имеет значения на некоторых платформах).
Как вы сказали, однако, было бы трудно попытаться выяснить, что это такое, заранее при именовании ваших заголовков. Таким образом, самый простой способ сделать это - установить путь включения на один уровень каталога вне подкаталога, в котором находятся ваши заголовки, например:
#include <Jonathan/String.h>
Теперь вам не нужно беспокоиться о том, будет ли String.h Имя файла конфликтует с чем-то в одной из используемых вами библиотек, если только они не включают , что маловероятно. Все приличные сторонние библиотеки тоже делают то же самое. Например, мы не включаем в boost, а вместо этого включаем . То же самое с GL / GL.h вместо просто GL.h. Эта практика позволяет избежать конфликтов по большей части, и вам не нужно обходить проблемы, переименовывая String.h во что-то вроде Text.h.
В OSX файловая система не чувствительна к регистру - поэтому String.h может привести к подобным конфликтам. String.h == string.h
Две вещи, с которыми вы столкнулись:
- Как отмечалось выше, файловая система в Mac OS нечувствительна к регистру, если вы специально не настроили свою файловую систему так, чтобы она была чувствительна к регистру.
- gcc не сильно различает локальные и системные пути включения заголовков. Когда вы указываете каталог, который будет добавлен к пути через -I, этот каталог будет использоваться для поиска как локальных, так и системных включений. Только когда вы используете -iquote или -I-, каталог пропускается при поиске system includes. Кроме того, встроенные каталоги «системных включений» на пути поиска компилятора всегда ищут локальные включения.
- Обратите внимание, что текущий каталог используется для локальных, но не системных включений. В этом случае я считаю, что он выбирает String.h, потому что настройки проекта явно добавляют каталог проекта верхнего уровня в путь включения.
Обходной путь, который я бы предложил, вместо того, чтобы переименовывать ваши включения, состоит в том, чтобы поместить ваши утилиты в каталог, имя которого уникально для вашего проекта, и указать этот каталог в вашей директиве include. Например:
#include "Josk/String.h"
и убедитесь, что самого Josk / нет в вашем пути поиска включения.Таким образом, вы не застрянете с неудобным переименованием, хотя вам, возможно, придется перетасовать некоторые файлы в своем проекте. Вам также может потребоваться отредактировать настройки вашего проекта, чтобы убедиться, что родительский каталог этого служебного каталога находится в вашем пути включения.
Еще одна возможность попробовать: если вы видите, что каталог проекта верхнего уровня добавлен к пути включения вашего проекта, удалите его. Это должно предохранять элементы в каталоге вашего проекта верхнего уровня от поиска системных включений.
Наконец, вы также можете избежать этой проблемы в данном конкретном случае, изменив чувствительность к регистру вашей файловой системы. Однако это может нарушить работу некоторых приложений Mac, поэтому изучите проблему, прежде чем приступить к этому - или выберите том, который больше не используется.
это сработало, если изменить имя String.h на Text.h
но это не имеет смысла, поскольку библиотека std включает свой собственный string.h, а не мой.
Я имею в виду, что разработчику нет смысла создавать свои файлы, думая о том, какие имена он не может использовать, для примера, допустим, я изменю свой String.h на Text.h (я уже изменил, мне нужно работать, а это не позволяет мне) и каким-то образом я должен включить другую шаблонную библиотеку, которая имеет include под названием Text.h, должен ли я снова изменить свой text.h или не использовать эту новую библиотеку? Должна быть альтернатива.
Или не должно?
спасибо за помощь,
Джонатан
Да, если вы используете
#include "file"
, сначала просматривается локальный каталог, а
#include <file>
просматриваются только системные включаемые папки.
Обратите внимание на слово сначала только в первом случае. Это означает, что при каждом включении ваша локальная версия никогда не будет достигнута (, если вы не включили исходный путь в директиву INCLUDE ).
Сказал, что мое фиктивное предложение - переименовать ваш локальный файл с недвусмысленным именем ...