Должен ли я использовать относительные пути включения для моего проекта или поместить каталог включения в путь включения?

Question

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

Например, в моем текущем проекте у меня есть network/server/myfile.hpp.Это должно включать common/log.hpp.В настоящее время я использую #include "../../common/log.hpp", что довольно многословно, но работает.

Если бы я вместо этого добавил свой основной каталог include в путь, я мог бы просто включить "common/log.hpp".

Я знаю этот вопросможет быть больше о предпочтениях, чем о чем-либо еще, но есть ли объективные плюсы и минусы в отношении кроссплатформенных приложений и как насчет соглашений C ++?

Answer 1

Относительно включает в себя пути с .. в нем выглядят немного уродливо и ожидают определенной структуры файловой системы, то есть "../../common/log.hpp" на две папки вверх. Имеет смысл избегать ненужных зависимостей вообще и от структуры файловой системы в частности, чтобы перемещение файла заголовка из одного каталога в другой не заставляло вас обновлять все исходные файлы, которые содержат этот заголовок.

Также элегантно, чтобы ваши включения соответствовали пространствам имен и классам. Если, например, у вас есть:

namespace foo { namespace bar { struct Baz; } }

Это удобно и интуитивно понятно, например:

#include "foo/bar/Baz.h"

Answer 2

Имея #include <common/log.hpp> в исходном файле и путь к common/log.hpp в настройках проекта (параметры компилятора), вы защищаете свой исходный код от изменений в случае, если common/log.hpp переместится в другое место, поэтому я бы порекомендовал этоподход.Обратите внимание на использование угловых скобок в этом случае - компилятор должен искать заголовок в каталогах, пути которых указываются параметром компилятора /I.

Answer 3

Я всегда стремлюсь сделать свои проекты независимыми от местоположения.Если я работаю на новом компьютере / платформе, я хочу иметь возможность компилировать и продолжать работать с минимумом необходимых настроек.Поскольку вы задаете субъективный вопрос, мой субъективный ответ будет таким: я определенно предпочитаю использовать относительные пути.

Answer 4

Нет КОНВЕНЦИЙ как таковых, вы можете сделать это любым способом, так, как вы предпочитаете.

Я имею в виду, если вы хотите сохранить порядок хотя тогда очевидно пойти на 2-й вариант, я бы сам пошел на второй одна причина не то, что вам придется переместить валун, но только несколько файлов, скажи главное.

Более того, относительные пути предоставляют вам свободу переноса приложения, так что просто сделайте это:)

Answer 5

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

Таким образом, каждый компонент использует свои собственные включаемые файлы с синтаксисом "", а другие компоненты включают использование <>, что позволяет избежать неприятных сюрпризов с одним компонентом, использующим заголовок, который включает в себя последняя развернутая версия, установленная в системе. каталог, а не из дерева исходных текстов; это также имеет приятный эффект, заставляя меня рано начинать компоненты.