Структура проекта C ++ под Visual Studio 2008 - PullRequest
Новая
       18

Структура проекта C ++ под Visual Studio 2008

3 голосов
/ 06 ноября 2008

Итак, я занимаюсь Java уже несколько лет, но сейчас я начинаю проект на C ++. Я пытаюсь определить лучшие практики для настройки указанного проекта.

В рамках проекта, как вы обычно структурируете их код? Вы делаете это в стиле Java с папками пространства имен и разбиваете свой источник таким образом? Вы храните ваши общедоступные заголовки в каталоге include для удобства ссылок?

Я видел оба и другие упомянутые способы, но каков хороший метод для большого проекта?

Кроме того, как вы относитесь к ресурсам / папкам в структуре вашего приложения? Это хорошо для окончательного проекта - установить папку log для хранения журналов, возможно папку lib для файлов библиотеки, возможно папку data для данных, но как вы управляете этими битами в проекте? ? Есть ли способ определить это так, что когда вы создаете решение, оно создает структуру для вас? Или вам просто нужно зайти в ваши встроенные папки конфигурации (Debug, Release и т. Д.) И создать структуру файла вручную, чтобы обеспечить правильное расположение путей, которые ожидает найти ваш EXE-файл?

Ответы [ 2 ]

1 голос
/ 06 ноября 2008

Мы стремимся сделать каждый компонент решением, содержащим один или несколько проектов (или подкомпонентов) и тестовый проект. Тестовый проект содержит все юнит-тесты.

Затем мы организуем решения в дерево на основе модулей и компонентов, например: 

//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution

Решение будет содержать несколько проектов Visual Studio: 

//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/Something
//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/SomethingElse
//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/TestTheSolution

Возможно, глубина дерева больше или меньше, в зависимости от количества имеющихся компонентов / подкомпонентов. Мы также склонны иметь «общее» решение на уровне подсистем и подкомпонентов с общим материалом многократного использования.

Затем у нас есть решение на уровне подсистемы, которое связывает все вместе для построения подсистемы.

Мы не используем и не экспортируем в каталог «include». Мы позволяем Visual Studio создавать и связывать в наших песочницах. У нас есть отдельная песочница "Release", чтобы мы случайно не связали неправильную библиотеку.

1 голос
/ 06 ноября 2008

У меня есть связанный, но другой вопрос, касающийся здесь . Я заявляю nmake, но на самом деле это любая система сборки: Scons, Bakefile, nmake, Ant, vcproj

Способ, которым я обычно структурирую свой код, - это «модуль» в приложении или DLL. Я не склонен использовать пространства имен, но это не значит, что вы не должны.

В IDE у меня есть что-то вроде этого: 

/solution
   /prj1
      /headers
        /module1
        /module2
      /resource
      /source
        /module 1
        /module 2
      /test
   /prj2
      /headers
        /module1
        /module2
      /resource
      /source
        /module 1
        /module 2
      /test

В файловой системе у меня что-то вроде этого: 

/solution
    /prj1
       /bin
       /build
       /include
          /module1
          /module2
       /lib
       /res
       /src
          /module1
          /module2
       /test
    /prj2
       /bin
       /build
       /include
          /module1
          /module2
       /lib
       /res
       /src
          /module1
          /module2
       /test
...