Как логически организовать исходные файлы в C++

Question

Область исходного файла быстро растет (с точки зрения количества файлов в моем проекте), и становится немного громоздко быстро найти конкретный исходный файл, который мне нужен для доступа на любом данное время. Я использую Embarcadero C++ Builder, но я столкнулся с этой проблемой и в других C++ IDE.

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

Есть ли у кого-нибудь идеи о том, как я могу достичь аналогичной функциональности на C++? Должен ли я отделять свой источник от физических папок? Создает ли C++ Builder какую-то функциональность виртуальной папки/группировки, которую я просто не вижу? Любые идеи приветствуются и благодарим вас.

Answer 1

Я вообще рекомендую не использовать (только) IDE или синтаксис языка для организации исходного кода. Во-первых, вы привязываетесь к окружающей среде: хорошо организованы в среде IDE, неорганизованные по файлу, а затем наступает тот день, когда вы можете использовать другую среду ...

Из-за этого я обычно использую все три способа организации моего источника в одно и то же время: я отделяю свой источник от функциональных модулей, т. е. связанных классов. Каждый модуль получает свое собственное пространство имен, физическую папку и папку IDE. (В моем случае, используя CMake и source_group() для создания файлов проекта IDE, если это необходимо. - лично предпочитает командную строку, Vim, и «делают»)

Следовательно, смотрите ли я на проекте внутри IDE, от в командной строке или из журнала компилятора foo/bar.cpp является foo/bar.cpp, это foo :: bar, минимизируя путаницу вокруг.

На самом деле, моя любимая в настоящее время установки дополнительно подразделяет каждый каталог модуля в <module>/<Class>.hpp или <module>/src/<Class>.hpp в зависимости от того, используется ли класс за пределами его собственного модуля или нет, <module>/src/<Class>.cpp и <module>/test/<Class>Tu.cpp. Пространство имен <module>::<Class>, конечно.

Но в конце концов, это очень зависит от вашего вкуса, от ваших со-разработчиков и объема вашего проекта.

Answer 2

Я делаю проекты, чтобы сохранить все мои файлы легко доступными. Это самый простой способ организовать, а также четкие имена классов/файлов.

Answer 3

Вот как я качусь:

PROJECT_NAME 
|-- build // This is DVCS ignored but has all the built intermediates and final binaries 
| |-- release // These are the different build profiles 
| |-- debug 
| |-- profile 
| `-- coverage 
|-- bin // For binary source code 
| `-- hello_world 
|  |-- doc 
|  |-- inc 
|  |-- src 
|  |-- tests 
|  `-- build_script // Builds binary into the build folder 
|-- include // Public headers for the library 
| `-- these 
|  `-- folders 
|   `-- represent 
|    `-- namespaces 
|     `-- my_awesome_class.hpp 
|-- lib // library source code 
| |-- these 
| | `-- folders 
| |  `-- represent 
| |   `-- namespaces 
| |    |-- inc // Private headers 
| |    | `-- my_private_class.hpp // internal class 
| |    |-- src // Source code for this namespace 
| |    | |-- posix 
| |    | | `-- my_awesome_class.cpp // posix specific source code 
| |    | |-- nt 
| |    | | `-- my_awesome_class.cpp // nt specific source code 
| |    | |-- my_private_class.cpp // non-visibile class 
| |    | `-- my_awesome_class.cpp // cross platform source code 
| |    |-- tests // Unit tests 
| |    | `-- my_awesome_class.cpp // builds a test executable for the library 
| |    `-- doc // Documentation for this namespace 
| |     `-- namespace.dox 
| `-- build_script // Builds binary into the build folder 
|-- doc // Documentation files 
| |-- main_page.dox 
| `-- namespace.dox 
`-- build_script // Builds the source code into the build folder 

Это представляет these::folders::represent::namespaces::MyAwesomeClass класс, который имеет posix и NT конкретный исходный код (а также общий исходный код), а также есть частный these::folders::represent::namespaces::MyPrivateClass, который используется внутри в библиотеки, заголовки не являются общедоступными и скрыты символы visibility символов класса.

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