Макет исходного кода проекта C++

один из популярных способов организации каталога проекта более или менее таков:

MyLib
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

MyApp
     +--other_class.h
        other_class.cpp
        app.cpp

app.cpp:

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

все .h и .cpp файлы для той же библиотеки находятся в том же каталоге. Чтобы избежать столкновения имен, имена файлов часто являются префиксом с именем компании и / или именем библиотеки. MyLib будет в пути поиска заголовка MyApp и т. д. Я не поклонник префиксов имен файлов, но мне нравится идея смотреть на #include и точно знать, где что файл заголовка принадлежит. Я не ненавижу этот подход к организации файлов, но я думаю, что должен быть лучший способ.

поскольку я начинаю новый проект, я хочу запросить некоторые идеи организации каталогов. В настоящее время мне нравится эта структура каталогов:

ProjA
    +--include
             +--ProjA
                    +--mylib
                           +--class_a.h
                    +--app
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--app
              +--other_class.cpp
                 app.cpp
                 util.h

app.cpp:

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp файлы и частные (только видимые для немедленной библиотеки).h файлы хранятся в каталоге src (src иногда называют lib). Публичных файлов заголовков организован в структуру каталогов проекта/lib и включен через <ProjectName/LibraryName/headerName.h>. Имена файлов не имеют префиксов. Если мне когда-либо понадобится упаковать MyLib для использования другими командами, я могу просто изменить свой makefile, чтобы скопировать соответствующие двоичные файлы и весь каталог include/ProjA.

как только файлы будут проверены в систему управления версиями и люди начнут работать над ними, будет трудно изменить структуру каталогов. Лучше получить его прямо с самого начала.

кто-нибудь с опытом организации исходного кода, как это? Что вам не нравится? Если у вас есть лучший способ сделать это, я бы очень хотел услышать об этом.

3 ответов


Ну, все зависит от того, насколько большой эти проекты. Если у вас есть только несколько файлов, а затем ударить их все в одной папке.

слишком много папок, когда у вас не так много файлов для управления, на мой взгляд, перебор. Это раздражает копаться в папках и из них, когда у вас есть только несколько файлов в них.

кроме того, это зависит от того, кто использует этот материал. Если вы пишете библиотеку и она будет использоваться другими программистами, то хорошо организовать заголовки они хотят использовать в папке include. Если вы создаете несколько библиотек и публикуете их все, ваша структура может работать. Но, если они являются независимыми библиотеками, и разработка не выполняется вместе, и они получают версии и выпускаются в разное время, вам было бы лучше придерживаться всех файлов для одного проекта, размещаемых в одной папке.

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

поцелуй, как правило, всегда решение в программировании - > держите все как можно проще.


почему бы не сделать что-то вроде Первого, только использовать каталог, который MyLib находится в качестве части директивы include, которая уменьшает глупый префикс:

#include <MyLib/ClassA.h>

это говорит вам, откуда они. Что касается второго выбора, я лично очень раздражаюсь, когда у меня открыт заголовок или исходный файл, и мне нужно перемещаться по структуре каталогов, чтобы найти другой и открыть его. Со вторым примером, если бы у вас было src/mylib/class_a.cpp открыть, и хотел отредактировать заголовок, во многих редакторах вам придется вернуться на два уровня, а затем в include/ProjA перед поиском заголовка. И как мы узнаем, что заголовок в ProjA подкаталог без какой-либо другой внешней подсказки? Кроме того, для одного файла или другого слишком легко переместиться в другое место, которое "лучше" представляет, как оно используется, без перемещения альтернативного файла. Это просто дает мне головные боли, когда я сталкиваюсь с этим на своей работе (и у нас есть некоторые части нашей кодовой базы, где люди делали все потенциальная проблема, о которой я только что упомянул).


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

обычно я использую это правило: приложения и внутренние библиотеки используют первый метод. Публичные библиотеки с открытым исходным кодом используют второй метод. Когда вы выпускаете код, это очень помогает, если включенные файлы находятся в отдельном каталоге.