Избегайте добавления «включаемых путей» для заголовков, которые не включены напрямую

Question

Предположим, у меня есть два проекта vc ++, proj_a и proj_b

proj_a содержит заголовочный файл a.h

proj_b зависит от proj_a. Он содержит файл b.h, который #include . Я добавляю каталог a.h в «дополнительные каталоги включения» в настройках его проекта.

Теперь скажите, у меня есть еще 100 проектов, файлы которых #include . Только добавление каталога b.h в столбец «дополнительный» не работает. Я тоже должен указать путь a.h .. Как этого избежать?

Проще говоря, как сохранить количество включаемых путей для любого проекта vc ++ равным количеству прямых зависимостей?

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

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

Answer 1

Спасибо за ответ, Ник. Я мог бы использовать относительный путь к a.h внутри b.h и сохранить дополнительные каталоги include-внутри proj_b и остальные 100 проектов.

На самом деле, в моем случае существует несколько разновидностей proj_a: 'proj_a1, proj_a2 и т. Д., Каждый из которых имеет отдельный a.h. Остальные 100 проектов решают, какой вариант включить, имея соответствующий каталог Additional-include-в своих настройках. Это было проблемой: всякий раз, когда нам нужно обновить версии proj_a, нужно будет изменить все include-dirs.

Я столкнулся с этой проблемой, удалив все include-каталоги и определив PROJ_A1, PROJ_A2 и т. Д. В остальных проектах. b.h больше не #include a.h, вместо этого он включает заголовочный файл a_redirector.h (с относительным путем). Внутри a_redirector.h у нас есть все #ifdef PROJ_A1, #ifdef PROJ_A2 и т. Д., Которые смотрят на включение конкретного файла a.h (относительные пути также здесь) в зависимости от того, что было определено.

Теперь, когда нам нужно обновить версии proj_a, мне нужно всего лишь изменить a_redirector.h, чтобы он указывал на все новые a.h, таким образом имея единую точку контроля по сравнению с более ранней архитектурой.

Answer 2

Зависимости являются переходными. То есть, поскольку b.h включает a.h, все, что включает b.h, должно быть в состоянии найти a.h. Единственное, что вы можете сделать, это как-то удалить зависимость b.h от a.h, возможно, используя прямое объявление для типов в a.h вместо полного определения типов из файла заголовка. .

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