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

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

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

1) Есть ли основания не иметь структуру папок например:

src/
 model/
 view/
 controller/

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

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

10
c++ namespaces packages

6 ответов

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

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

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

6

возможно, вы захотите взглянуть на Джон Лакос 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/
            ...

каждому пакету разрешено только #включать заголовки верхнего уровня другого пакета, никогда не в src/ справочники.

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

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

6

src / является общим местом, где программисты c / C++ помещают свои источники в корень проекта. Например:

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

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

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

1

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

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

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

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

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

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

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

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

0