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

Question

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

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

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

src/ 
model/ 
view/ 
controller/ 

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

Возможно, вы захотите посмотреть на John Lakos 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 5

ЦСИ/общее место есть C/C++ программисты поставили свои источники в корне проекта. Например:

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

это общие для создания поддиректории под SRC /, если у вас есть много исходников, но не существует никаких ограничений, как организовать эту подструктуру.

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

Answer 6

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

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

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

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

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

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

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