File organization survey
Author
Inquiring minds must know! How do you organize your source and header files?
Include and Source directories?
i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp
OR
Codebase/Foo.h, Codebase/Foo.cpp etc...
OR
Some other way?
What are the merits of one over the other? How should nested hierarchies work when using an Include/Source directory structure (i.e. Codebase/Include/FooLib/Foo.h OR Codebase/FooLib/Include/Foo.h)?
I know this is a silly question but please humor me. :-)
My reply won't help you directly since it's not C++, but I think it's also interesting to see how people organize in general - there is a lot more apart from code after all. You did say "survey", so that's my excuse for this somewhat tangential reply :)
Big disadvantage is that every processed asset is version-controlled twice, but I have more than enough disk space on my NAS so it hasn't been a problem yet. Asset pipeline in general is actually somewhat of a problem for me, but this is the "poor man's version" I came up with so far.
In SVN, my structure looks like:some-projectsome-other-project | |-tags |-branches |-trunk | |-(same as on disk, except for temp data)On disk, I have (for big project):sol-engine-core - separate from game to prevent dependencies | |-bin/ - compiled class files from Eclipse (not in SVN) | |-test/ - compiled unit test cases | |-core/ - compiled class files for project | |-src/ - contains game-specific source code (package tree) |-test/ - unit test cases source (package tree)solariad - game files proper, set up, game logic, game loop | |-bin/ - same as above, not in SVN |-content/ - first stage of asset pipeline, all raw assets are here | |-art/ | |-audio/ | |-models/ | |-data/ - contains all processed assets that are part of the game proper |-dist/ - the redistributable "gold master", where everything comes together during the build process (Ant script) This is not in SVN |-src/ - source package tree |-web/ - everything related to solariad.comBig disadvantage is that every processed asset is version-controlled twice, but I have more than enough disk space on my NAS so it hasn't been a problem yet. Asset pipeline in general is actually somewhat of a problem for me, but this is the "poor man's version" I came up with so far.
One of the standard linux layouts is to have the structure:
code/include/*.h
code/src/*.cpp
this is good for compilation and library linking.
1) everything that needs to be is already sperated, you don't have to do any extra work to pull the cpp files out of the library.
2) everything else is already in one place, so your #includes can be shorter and you need less include directories to send to the compiler.
On the other hand, for smaller projects and subsystems I prefer the layout:
code/stuff/*.h,*.cpp
It means less jumping around the folder structure when I'm looking for things. But it does mean that folders have 2x the number of files. And you tend to have a lot of folders.
Another structure I'm quite partial to is:
code/*.h
code/platform_pc/*.cpp
it has some of the benifits of the first approach, with the locality of the second aproach.
Besides, I'd rather edit X files when an interfaces changes then have to look at code that is a jumble of #if _PLATFORM_X_ directives.
[Edited by - KulSeran on May 31, 2009 7:32:14 PM]
code/include/*.h
code/src/*.cpp
this is good for compilation and library linking.
1) everything that needs to be is already sperated, you don't have to do any extra work to pull the cpp files out of the library.
2) everything else is already in one place, so your #includes can be shorter and you need less include directories to send to the compiler.
On the other hand, for smaller projects and subsystems I prefer the layout:
code/stuff/*.h,*.cpp
It means less jumping around the folder structure when I'm looking for things. But it does mean that folders have 2x the number of files. And you tend to have a lot of folders.
Another structure I'm quite partial to is:
code/*.h
code/platform_pc/*.cpp
it has some of the benifits of the first approach, with the locality of the second aproach.
Besides, I'd rather edit X files when an interfaces changes then have to look at code that is a jumble of #if _PLATFORM_X_ directives.
[Edited by - KulSeran on May 31, 2009 7:32:14 PM]
"Codebase/Foo.h, Codebase/Foo.cpp etc..."
That is the only one Visual Studio is friendly with, so it's the one I use.
That is the only one Visual Studio is friendly with, so it's the one I use.
Most of my projects are in C# so it's a little different, but for my projects I have folders for the different name spaces that I create and then all the source files for a name space go in that folder.
When I'm working with assets I tend to not keep them as organized as I should and have everything in the same Content folder. If I ever start work on a project big enough though I would probably have sub folders within the Content folder for UI, Models, Sound and anything else that the game would require.
When I'm working with assets I tend to not keep them as organized as I should and have everything in the same Content folder. If I ever start work on a project big enough though I would probably have sub folders within the Content folder for UI, Models, Sound and anything else that the game would require.
Author
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.
Let me pose an additional question; How useful would it be to have a number of sub-directories as an additional organizational structure? In other words, if you were working on your graphics renderer and had a number of files related to models and textures (ex. not just model.cpp but model_loading.cpp, model_rendering.cpp, model_exporter.cpp, texture_loading.cpp etc...), does it make sense to have a denser hierarchy like:
Renderer/D3D/Include/Models/Model_Rendering.cpp, Renderer/Common/Include/Textures/Texture_Loading.cpp, ...
Let me pose an additional question; How useful would it be to have a number of sub-directories as an additional organizational structure? In other words, if you were working on your graphics renderer and had a number of files related to models and textures (ex. not just model.cpp but model_loading.cpp, model_rendering.cpp, model_exporter.cpp, texture_loading.cpp etc...), does it make sense to have a denser hierarchy like:
Renderer/D3D/Include/Models/Model_Rendering.cpp, Renderer/Common/Include/Textures/Texture_Loading.cpp, ...
Quote:Original post by Dirge
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.
To an extent; but C and C++ have unique decisions to make because of the whole header vs. source file thing. :)
<project-name>/ env/<compiler-version>/<compiler>.sln * src/<project-name>/ src/ non-shared sources (usually .cpp & .hpp) inc/ shared sources (usually .inl and no-extention) env/<compiler-version>/ project specific data, usually just the .vcproj bin/<config>/<project-name>/ tempory build data dist/<config>/ distribution files, usually .dll and .exe* vs2005.sln for visual studio 2005 (by naming the solution after the compiler-version I can use it as a readable variable - anyone got any other options I'm all ears)
The reason behind this is that some projects will have to be build with several compilers. There is one project at work that needs to be built for visual studio 6.0 to 2008, both 16, 32 and 64 bits where applicable(supporting legacy application is fun).
For .net I've found the default to be sensible enough :)
Quote:Original post by gekko
"Codebase/Foo.h, Codebase/Foo.cpp etc..."
That is the only one Visual Studio is friendly with, so it's the one I use.
Visual studio can cope with /include and /src directories. Just remember to add the include path to your include paths in the project settings and you should be all set.
When adding files, You just have to add the path, so rather than adding foo.cpp, add src/foo.cpp
Anyway, at present I stick with
src/*.cpp
include/*.h
test/*.cpp;*.h
obj/<build string>/*.o
bin/<build string>/*.*
No doubt, given a few more years of experimenting it will change *shrugs*
Quote:Original post by DirgeWe used to do exactly that, until we realised how awful it was.
Include and Source directories?
i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp
The context menu item in VS "Go to header" doesn't work unless they are in the same dir.
What's more, adding both the source file and the header to a project requires browsing for files to add twice, rather than a multi-select in one directory.
Keep them in the same dir.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement