Я поддерживаю оба стиля ... для различного использования
Предположим, у вас также есть каталог root/src/common для моего примера
// in src/module1/foo.cpp
#include "module1/foo.h"
#include "../common/stringProcessing.h"
Включить
Я предпочитаю не видеть каталог 'include', поскольку, как сказано, конечно, найти точный заголовочный файл, таким образом, сложнее ... но когда вы начинаете и переходите к нескольким независимым библиотекам, вам НУЖНО абстрагироваться, потому что вы хотите быть в состоянии перемещать различные компоненты без изменения кода, и я все за последовательность.
Кроме того, всегда существует риск использования "..", что он не идет туда, куда вы думали, из-за символической ссылки, пройденной назад: /
Источник
Иногда у вас есть заголовки, которые не являются общедоступными и поэтому не находятся в каталоге include. Обычно это детали реализации, которые не имеют отношения к вашим клиентам. Я использую .., если необходимо, и уточняю точное местоположение.
Это позволяет:
- не загромождать -I всеми возможными каталогами src
- легко найти файл среди ваших источников
- легко проверять зависимости между вашими источниками (grep для ..)
Разное
Если мне нужно набрать
#include "module/foo.h"
Тогда я ожидаю использовать:
module::Foo myClass;
, что позволяет легко сопоставить один конкретный тип с одним конкретным модулем.
Требуемая одна библиотека - одно пространство имен с одинаковыми именами облегчает навигацию по некоторым ~ 300 или ~ 400 компонентам, которые у нас есть: мы ДОЛЖНЫ разработать какой-то способ их организации!
Это означает, что ваш первоначальный макет был переработан как (для проекта module):
root
-- include
---- module
------ part1
------ part2
-- src
---- part1
---- part2
И тогда вы используете следующую директиву: -I/path../root/include
И я ожидаю, что вы создадите либо libmodule.so библиотеку, либо module двоичный файл.