@kirsan_vlz

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

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

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

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

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

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


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

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

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

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

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

    #define USE_A
    #define USE_B
    
    #include "project.h"

    Автор писал, что такая структура удобна именно для больших проектов. Правда, это книга довольно старая и описывала еще C.
    Ответ написан
  • Riateche
    @Riateche
    Используйте третий вариант — cpp рядом с h, модули в подкаталогах. Добавьте корневой каталог проекта в include path. Внутри модуля инклюды делаются напрямую, инклюды с другими модулями пишутся относительно корневой папки.
    Ответ написан
  • Trrrrr
    @Trrrrr
    у нас я реализовал все хитрее:
    есть папка bin - туда попадает все скомпилированное.
    есть папка build - в ней файлы проектов (разделенный по папка под разные иде)
    есть папка sources - в ней папка совпадающие с именами проектов в сюлеше. т.е. например в солюшене у нас есть 3 проекта Core, Render, Game. Значит в папке сурсес у нас будут 3 таких же папки с такими же именами. В каждой из них в куче лежат и хедеры и сурсы.
    Каждый проект находится в своем namespace совпадающим с именем либы.
    И есть хедер со всеми инклюдами который выносятся из либы в наружу, т.е. с именем Core.h например. проекты к данным друг друга имеют доступ только через один единсвенный хедер.
    Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы