Макет исходного кода проекта 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
подкаталог без какой-либо другой внешней подсказки? Кроме того, для одного файла или другого слишком легко переместиться в другое место, которое "лучше" представляет, как оно используется, без перемещения альтернативного файла. Это просто дает мне головные боли, когда я сталкиваюсь с этим на своей работе (и у нас есть некоторые части нашей кодовой базы, где люди делали все потенциальная проблема, о которой я только что упомянул).
Я пробовал оба метода. Лично мне первое нравится больше. Я понимаю желание поместить все в более конкретные каталоги, но это вызывает много чрезмерных осложнений.
обычно я использую это правило: приложения и внутренние библиотеки используют первый метод. Публичные библиотеки с открытым исходным кодом используют второй метод. Когда вы выпускаете код, это очень помогает, если включенные файлы находятся в отдельном каталоге.