C++ project structure under Visual Studio 2008

Question

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 app 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 is expecting to find are properly positioned?

Thanks.

Answer 1

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

Answer 2

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

TheSolution will then contain several VS 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 SubSystem and SubComponent level with general re-useable stuff.

We then have a SubSystem-level Solution which ties everything together to build the SubSystem.

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