Хедеры в C/C++ — отдельные папки или вместе с исходниками? Подключать c путями или нет? Системные или обычные?
Интересует мнение по следующим вопросам:
1) Хранить хедеры вместе с соответствующими им исходными файлами или в отдельных папках?
2) Подключать хедеры с указанием пути или без? Т.е. #include "my_header.hpp" с подключением кучи папок в пути поиска хедеров или #include "some_path/my_header.hpp".
3) Добавлять ли папки проекта в пути поиска системных хедеров ( для подключения через #include <> ). С удивлением заметил, что всё больше проектов указывает свои папке хедеров, как системные.
Не холивара для, а образования ради. У меня уже 20 лет, как своя позиция по этим вопросам, которая, минимум трижды менялась за это время, ;) но подумалось, что возможно есть какие-то новые моменты, которые я упустил.
Мои типовые проекты это большей частью embedded где все исходники вместе с библиотекам в одном дереве исходников. Процент повторного использования кода между проектами довольно большой, но из-за железной специфики часто приходится патчить типовые исходники под конкретных проект.
До сотни файлов на типовой проект.
На данный момент хедеры хранятся в папках с соответствующими файлами исходников, либо в корне под-деревьев каких-подсистем программы, чтобы не искать потом какой заголовок от какого файла. В пути поисках подключен только корень исходных текстов и корни исходников библиотек, т.е. все пути к заголовкам указываются относительно корня.
Есть ли смысл делать иначе?
Я храню каждый программный модуль в отдельной папке. и хедер лежит рядом с реализацией. В свойствах проекта задаются пути ко всем папкам. Это дает возможжность перносить модули, и при этом не править вдруг пути для инклудов, если один модуль зависит от другого.
1.Хранят хидеры в отдельных папках в том случае, если это библиотека и нужно некоторый набор хидеров дать конечному пользователю. При этом внутренние хидеры могут лежать (и лежат) вместе с исходниками.
2. и 3. вообще без разницы.
Организация проекта у меня такая же как у вас. Работает нормально. Не вижу смысла что-то менять в этом плане.
