Спасибо за отличные ответы, особенно. Адам Стельмащик, ПиКуки и Аиб.
Как и многие программисты, я использовал неофициальное соглашение об использовании формы "myApp.hpp"
для файлов приложения и формы <libHeader.hpp>
для файлов библиотеки и системы компилятора, т.е. файлов, указанных в /I
и INCLUDE
переменная среды, в течение многих лет считая, что это стандарт.
Однако стандарт C утверждает, что порядок поиска зависит от реализации, что может усложнить переносимость. Что еще хуже, мы используем jam, который автоматически определяет местонахождение включаемых файлов. Вы можете использовать относительные или абсолютные пути для ваших включаемых файлов. т.е.
#include "../../MyProgDir/SourceDir1/someFile.hpp"
В старых версиях MSVS требовалась двойная обратная косая черта (\\), но теперь это не требуется. Я не знаю, когда это изменилось. Просто используйте косую черту для совместимости с 'nix (Windows примет это).
Если вы действительно переживаете по этому поводу, используйте "./myHeader.h"
для включаемого файла в том же каталоге, что и исходный код (в моем текущем, очень большом проекте есть несколько повторяющихся имен включаемых файлов, разбросанных по-- действительно проблема управления конфигурацией).
Вот пояснение MSDN , скопированное сюда для вашего удобства).
Цитируемая форма
Препроцессор ищет включаемые файлы в следующем порядке:
- В том же каталоге, что и файл, содержащий оператор #include.
- В каталогах открытых на данный момент включаемых файлов, в обратном порядке, в которых
они были открыты. Поиск начинается в каталоге родительского включаемого файла и
продолжается вверх по каталогам любых включаемых файлов прародителя.
- Вдоль пути, указанного каждым параметром компилятора
/I
.
- Вдоль путей, указанных в переменной среды
INCLUDE
.
Форма углового кронштейна
Препроцессор ищет включаемые файлы в следующем порядке:
- Вдоль пути, указанного каждым параметром
/I
компилятора.
- Когда компиляция происходит в командной строке, по путям, указанным в переменной среды
INCLUDE
.