Should I put classes in separate files in C++? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expe开发者_运维问答rtise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

I am asking this question to organize my code.

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++.

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.

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

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.

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

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.