конфликтует с моим собственным String.h

Question

У меня есть проект, который нормально компилировался в g ++ (сейчас я не вижу версию), а сейчас в xCode его нет.
Я думаю, что у меня сейчас проблема ... У меня есть строка.h файл в моем проекте, и кажется, что компилятор xCode (то есть gcc) пытается добавить свой собственный строковый файл из ... Я не уверен в этом, но взгляните на эту картинку
http://www.jode.com.br/Joe/xCode1.png

из того, что выглядит, оно включает в себя мой собственный файл, а не системный файл, мне было интересно ... разве не #include должно быть включением системы?из-за <>?и не должна ли система включать файл в свой собственный путь, а не в исходный путь моего приложения?
Как я уже сказал, я не уверен, что это происходит, потому что я только что перешел на osx в последние 2 дня...
Я собирался изменить свой класс и имя файла, чтобы оно не конфликтовало, поэтому это сработало бы, если бы это действительно было проблемой, но мне было интересно, должен быть другой способ сделать это, потому что теперь мой проект нене такой большой, чтобы я мог сделать это через некоторое время, но что, если проект был больше?было бы трудно изменить все включения и имена классов ...

Любая помощь приветствуется

Спасибо,
Джонатан

Answer 1

У меня была такая же проблема, и ее было трудно решить.Потребовались мои часы, чтобы исправить / выяснить.проблема в заголовочной карте xcode.и решение - помимо того, что нужно избегать такого рода зарезервированных имен, что в целом является хорошей идеей, но не всегда возможно для сторонних библиотек, - добавить

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

Answer 2

Наименование ваших заголовков с теми же именами, что и у стандартных заголовков, например string.h , и включение их просто с помощью #include <String.h> вызывает проблемы (разница в регистре не имеет значения на некоторых платформах).

Как вы сказали, однако, было бы трудно попытаться выяснить, что это такое, предварительно называя ваши заголовки. Таким образом, самый простой способ сделать это состоит в том, чтобы задать для пути включения один уровень каталога вне подкаталога, в котором находятся ваши заголовки, например:

#include <Jonathan/String.h>

Теперь вам не нужно беспокоиться о том, не конфликтует ли имя файла String.h с чем-то в одной из библиотек, которые вы используете, если только они не содержат <Jonathan/String.h>, что маловероятно. Все приличные сторонние библиотеки делают это также. Например, мы не включаем <function.hpp> в boost, но вместо этого включаем <boost/function.hpp>. То же самое с GL / GL.h вместо просто GL.h. Эта практика по большей части избегает конфликтов, и вам не нужно обходить проблемы, переименовывая String.h в что-то вроде Text.h.

Answer 3

Да, если вы используете

#include "file"

, сначала просматривается локальный каталог, а

#include <file>

- только системные папки включения.

Обратите внимание на слово first только в первом случае.Это означает, что при каждом включении ваша локальная версия никогда не будет доступна (, если вы не включили исходный путь в директиву INCLUDE ).

Сказал, что мое фиктивное предложение состоит в том, чтобы переименоватьлокальный файл с однозначным именем ...

Answer 4

это сработало, изменив имя с String.h на Text.h

но это не имеет смысла, поскольку библиотека std включает в себя собственный string.h, а не мой.
Я имею в виду, что для разработчика нет смысла создавать свои файлы, думая о том, какие имена он не может использовать, например, скажем, я изменил свой String.h на Text.h (я уже сделал, мне нужно работать, и это не позволяет мне), так или иначе, я должен был включить другую шаблонную библиотеку, которая имеет включение, называемое Text.h, я должен буду изменить свой text.h снова или не использовать эту новую библиотеку? должна быть альтернатива.
Или не должен?

спасибо за помощь,
Jonathan

Answer 5

В OSX файловая система нечувствительна к регистру - так что String.h вы можете столкнуться с подобными конфликтами.String.h == string.h

Answer 6

Две вещи, с которыми вы сталкиваетесь:

1. Как отмечалось выше, файловая система в Mac OS нечувствительна к регистру, если вы специально не настроили свою файловую систему так, чтобы она чувствительна к регистру.
2. gcc не делает различий между локальными и системными заголовками, включая пути. Когда вы указываете каталог, который будет добавлен к пути через -I, этот каталог будет использоваться для поиска как локальных, так и системных включений. Только когда вы используете -iquote или -I-, каталог пропускается для определения местоположения системы. Кроме того, встроенные каталоги «system include» в пути поиска компилятора всегда ищут локальные включения.
   • Обратите внимание, что текущий каталог используется для локальных, но не системных включений. В этом случае, я полагаю, он подхватывает String.h, потому что настройки проекта явно добавляют каталог проекта верхнего уровня в путь включения.

Обходной путь, который я бы предложил вместо переименования ваших включений, - это поместить ваши утилиты в каталог, имя которого является уникальным для вашего проекта, и указать этот каталог в вашей директиве включения. Например:

#include "Josk/String.h"

и убедитесь, что Josk/ сам по себе не входит в ваш путь поиска для включения. Таким образом, вы не застряли с неудобным переименованием, хотя вам, возможно, придется перетасовать некоторые файлы в вашем проекте. Вам также может потребоваться изменить параметры проекта, чтобы убедиться, что родительский каталог этого служебного каталога находится в пути включения.

Еще одна возможность попробовать, если вы видите каталог проекта верхнего уровня, добавленный к пути включения вашего проекта, удалите его. Это должно предотвратить поиск элементов в каталоге проекта верхнего уровня для системных включений.

Наконец, вы также можете избежать этой проблемы в данном конкретном случае, изменив чувствительность к регистру в вашей файловой системе. Однако это может привести к поломке некоторых приложений Mac, поэтому изучите проблему, прежде чем приступить к этому, или выберите том, который больше не используется.