How do I layout my C++ program? (where should I put the .h and .cpp files?)

Currently, I program in Java and 开发者_StackOverflow社区use Maven quite a bit. As so I've become accustom to the naming schemes and folder structures that I've used over the past 4 or 5 years.

As I have recently started to learn C++, I'm realizing that I have no idea where to put all my files. Should I keep everything broken down by namespace, or by what tier it is in? Where, for example, would I keep a series of files devoted to UI, as apposed to files meant to help store data?

Are there any standards for this sort of thing?

Clearly, there is no definitive answer to this question. I'm simply looking for a good guide. I do not want to start learning C++ by spending too much time worrying about how my files are laid out. I'd rather have some good models, and just get to the coding.

The following is fairly typical...

third-party library
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

mylibrary
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

myapp
  release
    obj
  debug
    obj
  subapp 1
  subapp 2

mylittleapp
  release
    obj
  debug
    obj

Basically, subfolders for subprojects is common for larger projects, but mostly a particular project has folders for src, include etc. A folder for each build configuration is common, and keeping the obj files and other intermediates in a subfolder of that is a good idea. It may be tempting to put subproject folders in obj folders, but usually that's unnecessary - the obj folders don't need to be well organised, so the only concern is a filename conflict, and the best fix for that is to have unique source filenames within (at least) each project.

The "include" folders should IMO only contain headers that will be #included by other projects - internal headers belong in the "src" folder.

Putting UI stuff in a separate folder isn't a bad idea, if it's big enough. I've seen UI stuff done as a separate static-linked top-level project, and I do mean app-specific here, not (e.g.) wxWidgets. Usually, though, that level of division is sub-project if it's worth separating at all. How you divide subprojects is more a matter of application-specific blocks in general, so it depends on whether UI stuff is best handled as a separate block or as separate chunks mixed in with task-specific logic.

Namespaces aren't the most used language feature, possibly because a lot of people use "using" so much they don't make much difference. A namespace for a main library project makes sense, but associating subfolders to namespaces 1:1 isn't something I've seen. I personally have a namespace that encompasses most of my library code, with a couple of sub-namespaces for things rarely used in general, but used a lot in a few places (e.g. a "bitwise" namespaces). The sub-namespaces are limited to single source/header pairs, so no need for subfolders. Most of the library-specific selection is done by including the right header - except that I usually include the lot through a main-project top-level header anyway.

Basically, namespaces are a way of avoiding naming conflicts. They don't necessarily associate with abstractions or functional blocks or anything. Within a particular project, you're probably better off just making sure the names don't conflict. As with the "std" namespace, it's fine to put a lot of stuff in one namespace.

As you say, though, this isn't a definitive answer - there are of course minor variations and quite different approaches.

On small projects my team groups all the files together by a link unit ie library, DLL, EXE. If the unit is very large we will sometimes breakup the files by functional unit or subsystem so that if you need to edit a component they are generally in the same place.

I break my projects by theme, one directory for theme:

menu_planner
  src
     recipes
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     ingredients
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     references
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     meals
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     menus
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
  docs
     designs

My experience with C and C++ has shown to me that header and source files should be in the same directory. Often, finding a header file is more difficult when it is not in the same directory as the source file.

One directory (folder) per concept is a good idea. Any concept that is complex or compound should be split into multiple folders or concepts.

I've also learned to make libraries. I use libraries to contain code that doesn't change much. The linking step performs faster with libraries than directories of object files.

However, work places (a.k.a. shops) may have different style rules that must be followed.

It is not necessary to have your header files and cpp files in the same folder. I have done this many times. You can have the in different folders and use another file to fetch/include both files on file, which you will use as your include.