| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > #include "folder/file.h" vs #include "file.h" |
| Автор: semibug 9.11.2009, 18:46 |
| Всем известны варианты подключения файла через #include: либо указываем путь в #include (абсолютный или относительный), либо в #include указываем только имя файла, а путь к папке подсовываем компилятору через опцию -I. Стоит задача выбора способа задания путей для большого проекта. Вижу такие плюсы/минусы вариантов: 1. (прописать путь в #include ) + возможность использования двух и более файлов с одинаковым именем в разных папках + при составлении Makefile не надо описывать кучу директорий в -I + если папок много, найти файл проще (по пути) - для реорганизации расположения исходников придется переписать много #include-ов 2. (прописать в -I ) + исходники можно реорганизовывать (перемещать по папкам) без необходимости править #include-ы ... (в общем в точности наоборот к первому варианту) Расскажите пожалуйста свои с какими плюсами и минусами обоих вариантов вы встречались. |
| Автор: Alek86 9.11.2009, 18:55 |
| я обычно добавляю в проекты только стандартные пути (те, что по-умолчанию и буст) а также $(ProjectDir) и $(SolutionDir) при этом простое правило - если файл находится в том же проете, то инклудится через #include "" если это библиотечный или с другого проекта - то через #include<> потому инклудов вида #include "../../Proj/file.h" у меня практически не бывает и мороки минимум |
| Автор: semibug 9.11.2009, 18:58 |
| Alek86, т.е. Вы практикуете расположение всех исходных файлов проекта в одной директории? |
| Автор: Alek86 9.11.2009, 19:11 | ||
нет, но вложенности не большие, потому к файлам легче обратиться через "корень" потому я и сказал, что не бывает практически, то бишь редко  если вы пишете как в джаве, с 3-4 вложенными неймспейсами, то, наверное, легче использовать ".." |
| Автор: semibug 9.11.2009, 19:57 | ||||
| Google C++ Style Guide рекомендует прописывать пути без переходов на уровень выше (..), а исключительно от корня проекта. В совокупности с
выходит неплохое решение. недостаток
решается поиском/заменой, так как теперь пути фиксированные и не содержат отличий (как в варианте с переходами по ".." ). |
| Автор: jonie 9.11.2009, 21:51 |
| у меня стандартная картина расположения файлов: libs\ src\Project.sln src\Project1Dir\ src\Project2Dir\ ... tools\ bin\ все собирается в bin, в tools автосборщики, в lib все lib и нужные хедеры (например для xerces парсера есть папка xerces\внутри которой хедеры, сам же xerces.lib будет лежать в libs). Соотвественно -I указан (кроме буста, и прочих "стандартностей" еще и $(SolutionDir)/../libs/ достаточно удобно, кроме того "все в одном".... зачастую в libs лежат архивы библиотек, которые надо распоковать. Девелопер распакует их сам (и если надо соберет). Сама же сборка производится только конвеером с помощью скриптов в tools, при этом собираются и все библиотеки с libs. Собираются ибо хрен его знает какие там настройки компилятора будут на конвеере, да и сам компилятор хрен знает каких версий, сервис паков и т.д. - вобщем "от греха подальше"..... Если кто может предложить что-то более вразумительное, то с удовольствие послушаю Добавлено через 2 минуты и 30 секунд да, если есть два проекта, второй из которых зависит от первого, то, в случае использования subversion на него идет svn:externals в папке libs (т.о. он также скачивается в либы, и если надо собирается).... такие же трюки можно провернуть и в mercurial\git\ваш_любимый_FVCS |
| Автор: Alek86 9.11.2009, 23:35 |
| jonie, а как ты досукиваешься до файлов с других проектов? |
| Автор: jonie 10.11.2009, 00:14 |
| Alek86, прочитав внимательно, можно заметить добавленое. в большинстве случаев, я, как программист, делаю вместо svn:externals на своей машине реальную soft-link ссылку на "другой проект", нежели скачиваю его "еще раз". обычно "другой проект" содержит все свои include-ы в одной папке (имя которой обычно совпадает с именем проекта), на родителя которую делается -I проекта, ссылающегося на этот.... можно и в других системах делать такие же вещи, это не проблема вроде бы... |
| Автор: Alek86 10.11.2009, 10:40 |
| не очень понял получается, что svn:externals как-то влияет на include directories в колмпилере? |
| Автор: jonie 10.11.2009, 10:45 | ||
| Alek86, нет. пусть у нас два проекта А и Б, Б зависит от А. Тогда структура будет такая:
где libs\A подключен через svn:externals (поэтому там появитс src\А собственно). Сам проект Б настроен так: -I $(SolutionDir)\..\libs\A\src\ в проекте Б, хедеры подключаются через include <A\megaheader.h> |
