CODEWITHSUNDEEP
c++projectstructure
scubabbl
scubabbl

Reputation: 12797

C++ project structure under Visual Studio 2008

So, I've been doing Java for a number of years now, but now I'm starting a C++ project. I'm trying to determine best practices for setting up said project.

Within the project, how do you generally structure their code? Do you do it Java style with namespace folders and break up your source that way? Do you keep your public headers in an include directory for easy referencing?

I've seen both and other ways mentioned, but what's a good method for a large project?

Also, how do you deal with resources/folders in your application structure? It's all well and good for the final project to install with a log folder for storing logs, maybe a lib folder for library files, maybe a data folder for data, but how do you manage those bits within the project? Is there a way to define that so when you build the solution it constructs the structure for you? Or, do you simply have to go into your built configuration folders (Debug, Release, etc.), and construct the file structure manually, thus ensuring paths your EXE file is expecting to find are properly positioned?

Upvotes: 3

Views: 2921

Answers (2)

metao
metao

Reputation: 2844

We tend to make each component a solution, containing one or more projects (or sub-components) and a test project. The test project contains all of the unit tests.

We then arrange the solutions into a tree based on modules and components, for example:

//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution

The solution will then contain several Visual Studio projects:

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

There might be more depth to the tree, or less, depending on the number of components/sub-components there are. We also tend to have a "General" solution at the sub system and sub component level with general re-useable stuff.

We then have a sub system-level solution which ties everything together to build the sub system.

We do not use or export to an "include" directory. We let Visual Studio build and link within our sandboxes. We have a separate "Release" sandbox to ensure we don't accidentally link the wrong library.

Upvotes: 1

Zach Burlingame
Zach Burlingame

Reputation: 13806

I have a related, but different question going on over here as well. I state nmake, but really it's any build system: Scons, Bakefile, nmake, Ant, vcproj

The way I generally structure my code is by "module" within an application or DLL. I haven't tended to use namespaces, but that doesn't mean you shouldn't.

Within the IDE I have something like this:

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

On the file system I have something like this:

/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

Upvotes: 1

Related Questions