структура src / папок в C ++?

Question

Я вхожу в C ++ из Java / AS3-land, и я привык к структуре package-cum-folder для моих классов. и мне это нравится.

Я понимаю самые основы пространств имен в C ++, и я рад оставить это только в основе. но, поскольку мой проект становится все более сложным, я бы хотел, чтобы структура моей папки была организована так, чтобы я мог держать ее в голове. то есть что-то похожее на Java / AS3.

1) есть ли причина для не иметь структуру папок, такую ​​как:

src/
 model/
 view/
 controller/

возможно с подпапками? (это просто пример MVC, структура папок может быть любой, в зависимости от потребностей проекта.) Просто кажется неуправляемым иметь папку src / с огромной кучей заголовочных и исходных файлов внутри.

2) если бы ответ на 1) мог бы быть «продолжай и делай, что хочешь», было бы неразумно / ненужно создавать пространство имен для каждой папки, аналогично Java / AS3, способ создания пакета для каждой папки ? Насколько я понимаю, пространства имен обычно не используются таким образом, они глубоко вложены и связаны с папками.

Answer 1

Мне всегда нравилось пространство имен для каждой папки.Главным образом потому, что когда мне приходится поддерживать чужой код, пространство имен помогает мне найти, где класс был первоначально определен.Я также не рекомендовал бы использовать более 2-3 пространств имен, так как тогда это становится просто неприятным.Вы обнаружите, что используете «использование пространства имен, бла»;многое, что я всегда нахожу красным флагом для кода C ++.И вы не можете использовать «использование пространства имен» внутри заголовочного файла без каких-либо серьезных проблем.

Это все совершенно необязательно, хотя в C ++.

Answer 2

Возможно, вы захотите взглянуть на Джона Лакоса Large-Scale C++ Software Design.В принципе, вы можете сделать это, но ваши пакеты должны (как в Java) иметь ациклический граф зависимостей.Кроме того, для каждого пакета может быть уместно документировать, какие заголовки экспортированы, а какие нет, может быть так:

src/
 |- package1/
     |- exported_symbols_1.hh
     |- exported_symbols_2.hh
     |- src/
         |- impl_1.hh
         |- impl_1.cc
 |- package2/
     |- sub_package_2_1/
         |-  exported.hh
         |-  src/
                 ...
      |- src/
            ...

В каждом пакете разрешено только #include заголовки верхнего уровня другого пакетаНикогда в каталогах src/.

Кроме того, когда вы хотите использовать Autotools в большом проекте и намереваетесь распределить заголовки, может оказаться целесообразным вызывать каталог верхнего уровня, а не src/, но PACKAGE_TARNAME этого проекта.Это облегчает установку заголовков с помощью Autotools.

(И, конечно, реальные имена файлов выглядят не так глупо, как показано выше.)

Answer 3

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

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

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

• факторов, предполагающих использование большего количества пространств имен
  • очень изменчивый код (часто редактируемый, постоянное добавление / изменение идентификатора, часто короткие и / или общие слова)
  • больше разработчиков
• факторы, уменьшающие потребность в пространствах имен
  • жесткая координация со стороны центрального органа
  • запланированные официальные выпуски с тщательными проверками на наличие конфликтов

Пространства имен также можно использовать как способ, позволяющий легко переключаться между альтернативными реализациями (например, различными версиями протокола, поточно-ориентированными и небезопасными функциями поддержки, реализациями, специфичными для ОС), поэтому иногда удовлетворение таких потребностей включает использование Пространства имен.

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

Итак, вы можете учитывать эти факторы при принятии решения о том, помещать ли код каждой папки (или какую-либо другую логически отличную группу) в разные пространства имен.

Answer 4

src / - это обычное место, где программисты на c / c ++ размещают свои источники в корне проекта. Например:

doc/    <- documentation
libs/   <- additional libraries
po/     <- gettext translations
src/    <- sources

Обычно подкаталоги создаются под src /, если у вас много исходных файлов, но нет ограничений по организации этой подструктуры.

Имейте в виду, что структура каталогов полностью необязательна в c ++. Это не связь между пространствами имен c ++ и структурой каталогов.

Answer 5

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

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

Answer 6

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

1. Не над -новыми папками, это может сбить с толку читателей вашего кода.
2. Будьте последовательны в организации вашего кода, например, не помещайте любой код представления в подкаталог контроллеров, или наоборот.
3. Содержите макет в чистоте.