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

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

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

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

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


project c++ structure
person scubabbl    schedule 06.11.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

//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

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

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

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

person metao    schedule 06.11.2008

arrow_upward
1
arrow_downward

У меня есть связанный, но другой вопрос по и здесь. Я называю 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
person Zach Burlingame    schedule 06.11.2008