Организация исходников C++?

Question

[kirsan_vlz]

По ходу изучения языка программки становятся всё больше и возник вопрос организации исходников.

Несколько часов гуглил, но толкового ничего не нашёл. Выделил следующие варианты:

1) Всё кидается в один каталог, тогда заголовки инклудятся очень просто.

2) Единицы компиляции в одном каталоге, заголовки в другом. Тогда усложняются инклуды за счёт перехода через родительский каталог.

3) Разбиваются модули, в которых заголовки и единицы компиляции лежат в куче. Тут не совсем ясно как связывать модули.


Ещё не совсем понял с установкой include path в makefile. Если указать этот параметр, то, например для #include someHeader.h", компилятор будет искать файл someHeader.h не только в каталоге компилируемого cpp-файла, но и по указанному в параметре пути?

И ещё что-то видел про задание префиксов в #include.

Answer 1

[darkslesh]

Для себя сделал такую структуру (часто использую в проектах если больше 3 тысяч строк)
1) Всё лежит в одном месте
2) C/CPP файлы содержат код, а в заголовке содержат include «header.h»
3) все H файлы содержат прототипы функций, константы и структуры, которые относятся в C/CPP файлу.
4) в файле header.h прописываются все заголовочные файлы (сначала системные, потом свои)

Таким образом очень легко править всё что связано с одним файлом кода (H и CPP файлы имеют одно имя, ток расширение разное). При добавлении нового модуля, нет необходимости прописывать его заголовочный файл в каждом исходнике где он используется, достаточно прописать только в header.h

И к тому же такой подход позволяет легко обходить ситуации с взаимный include (первый на второго, а второй на первый)

Comments

[kvabr]

Эх, никогда вы не сталкивались с проблемами перекрёстных зависимостей.
Хедера инклудить надо ТОЛЬКО в .cpp. Ни в коем случае не в .h.
Любой проект чуть сложнее хеллоуворлда — от подключений хедеров в хедера начинает биться в предсмертных конвульсиях ещё на первом десятке модулей или объектов.

[Fil]

Еще в header приходится засовывать определения шаблонных классов/функций, из-за отсутствия возможности их экспорта.

[kirsan_vlz]

По поводу подключения h в хэдерах — а если у меня в b.h используются типы, объявляемые в a.h?

[Ritter]

forward declaration? А, непосредственно работа с типами, будет в CPP.

[kirsan_vlz]

Благодарю, то ли не знал, то ли забыл про эту возможность.

Answer 2

[MikhailEdoshin]

Читал в свое время совет, но сам не пробовал (мои проекты не очень сложные) — пишется один .h-файл на весь проект, но каждая логическая секция в нем завернута в

#ifdef USE_A
...
#endif

.
В исходниках соответственно сначала определяется, что использовать, а затем включается .h-файл:

#define USE_A
#define USE_B

#include "project.h"

Автор писал, что такая структура удобна именно для больших проектов. Правда, это книга довольно старая и описывала еще C.

Comments

[Дмитрий]

Не уверен что полностью понял о чем тут, можете переформулировать мысли?

Answer 3

[Riateche]

Используйте третий вариант — cpp рядом с h, модули в подкаталогах. Добавьте корневой каталог проекта в include path. Внутри модуля инклюды делаются напрямую, инклюды с другими модулями пишутся относительно корневой папки.

Comments

[kirsan_vlz]

А с подключениями заголовков в заголовках как поступать? Forward declaration не всегда помогает, насколько я понял.
Например, объявляю в файле a.h класс из другого файла b.h, но в том же файле a.h у меня есть шаблон, в реализации которого используется объявленный класс. И получается, что либо определение шаблона выносить (а это возможно?) или подключать b.h в a.h.

Answer 4

[Trrrrr]

у нас я реализовал все хитрее:
есть папка bin - туда попадает все скомпилированное.
есть папка build - в ней файлы проектов (разделенный по папка под разные иде)
есть папка sources - в ней папка совпадающие с именами проектов в сюлеше. т.е. например в солюшене у нас есть 3 проекта Core, Render, Game. Значит в папке сурсес у нас будут 3 таких же папки с такими же именами. В каждой из них в куче лежат и хедеры и сурсы.
Каждый проект находится в своем namespace совпадающим с именем либы.
И есть хедер со всеми инклюдами который выносятся из либы в наружу, т.е. с именем Core.h например. проекты к данным друг друга имеют доступ только через один единсвенный хедер.