13

I am asking this question to organize my code.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Datoxalas
  • 1,261
  • 5
  • 14
  • 23
  • possible duplicate of [How many classes should a programmer put in one file?](http://stackoverflow.com/questions/469887/how-many-classes-should-a-programmer-put-in-one-file) – Suma Apr 05 '11 at 11:28
  • 1
    You'd better make the call based on what your compiler can do. Having it loaded and initialized for each individual class in your project could lead to rather brutal compile times. – Hans Passant Apr 05 '11 at 13:00
  • Hans: I don't think this really is an issue with a modern development workstation with a SSD. Can you back your comment up with numbers? In any case, do you really want to organize your project for the benefit of your compiler? Humans spend longer editing than they do building. – paperjam Apr 05 '11 at 13:11
  • 1
    @paperjam: the only reason I use .cpp files at all (well, past the first one per executable) is for the benefit of my compiler, so yes I do organize my projects bearing in mind how they build. I expect Hans does to, that's just life in C++. – Steve Jessop Apr 05 '11 at 18:27
  • 1
    @Steve Jessop Good point, but another use of multiple cpp files is namespace separation. For example, preventing polluting namespace of portable code. Other human benefits too. Interesting discussion. – paperjam Apr 06 '11 at 10:56
  • 1
    @paperjam: yes, fair point, it arises when headers put anything in the global namespace (including macros for this purpose), and especially with `windows.h` in particular since it breaks some standard things. So I exaggerate a bit, but the organisational benefits of separate files can be achieved with separate headers. A lot of the time the reason specifically for using .cpp files rather than sticking pretty much everything in headers is to get decent incremental rebuilds. So build time is a concern, unfortunately. – Steve Jessop Apr 06 '11 at 11:03

6 Answers6

12

C and C++ convention is one header file per library, or section of a library, rather than one header file per class. Try to group related classes together. So for example in the standard libraries <set> contains both std::set and std::multi_set, but then those are templates that do very similar things.

There isn't any truly consistent rule for public headers, though - Boost.asio has a big header file with a lot in it. Boost.DateTime is divided reasonably far down, although still not to the level of a single type.

You can put the implementations of the member functions in one source file per class if you like. Even one source file per function if you're following the GNU C style, although I don't think I recommend that for C++. And you could always implement your public-facing header files by having them include multiple separate headers.

It might depend as much on your version control and build processes as anything else - it's convenient to change a class without touching any files containing anything unrelated to the class, since then the bare minimum rebuilds and the changelog clearly identifies what has changed from the filename. But a class isn't necessarily the boundary of what's considered "unrelated code".

For example if you're writing collections with iterators, or classes that register listeners with some framework where the listener will act back on the main class, it doesn't make much sense to separate them. Morally speaking those are "inner classes" even if you don't implement them as nested classes in C++.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • That might be the convention of the stdlib and Boost, but as a complete hunch, I'm really not sure it's a convention of most _user_ code, and I think we all know we shouldn't try to emulate either of those libraries' styles in user code. Great points about VC and "inner classes" though. – underscore_d Nov 13 '16 at 23:39
  • @underscore_d: It's true, I can't say anything that applies universally to all C and C++ programmers. In any language you get people who've come from Java and who (at least to start with) consider it a sin to put more than one class implementation in a source file. As I say in the answer, it's fine to work that way and C++ supports it. When it comes to headers, though, I think it's fair to point to the standard headers as "permission" to group things together. Go with what's convenient for developing, since you can add a library-wide header later for user convenience avoiding too many #include – Steve Jessop Nov 23 '22 at 12:42
4

I like to keep related classes in the same file.

For example, if I had a functor that was used in a for_each loop within a different class then I wouldn't generally put it in its own file. This seems excessive - and separates the code from where it is to be used too much.

However, in general I try to separate the classes out, and try have a sensible tree structure for the .hpp files that group together their use. At the head of this tree I like to have a catch all header file that includes the whole library.

Tom
  • 5,219
  • 2
  • 29
  • 45
3

Yes. As a general rule, one class per pair of .h/.cpp. Files should be named after the class.

Erik
  • 88,732
  • 13
  • 198
  • 189
1

It depends on the application. With some applications, it makes sense to group different classes together in one set of .h/.cpp files if they are tightly coupled. Otherwise the standard of splitting a class into header and source files is definitely the proper way to do it.

g19fanatic
  • 10,567
  • 6
  • 33
  • 63
1

You should put C++ classes in separate files if it makes sense to do so. With well designed classes, it often does. It makes for easy coding, maintenance, modularity, refactoring and reuse.

Then you have MyClass.h which contains class MyClass {...} and MyClass.cpp which contains all of MyClass's methods.

If you have lots of small classes, this gets a bit crazy so consider a couple of options:

  • File named after a namespace, e.g. MyNamespace.h, MyNamespace.cpp
  • Nested classes - does it make sense to wrap a class definition inside another class? By doing this you are saying that the nested class is unlikely to be useful without its parent.

It is nice to avoid an extra set of naming conventions, by making each file name consistent with a C++ namespace or class names one avoids the need to think up new names or convert from one convention to another.

Google style guide has an opinion too, preferring filenames with underscore. See http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#File_Names

paperjam
  • 8,321
  • 12
  • 53
  • 79
-3

Yes it is a good practice to keep separate classes in separate cpp files and then name the files by using the class name. In fact Java forces you to do so.

Alok Save
  • 202,538
  • 53
  • 430
  • 533