Organizing C ++ Class Header Files

Question

What are the coding and directory recommendations in C ++ that you offer for people who have to deal with a large number of interdependent classes distributed across multiple source and header files?

I have this situation in my project and resolving the error class classes that cross multiple header files has become quite a headache.

Answer 1

Some general recommendations:

• Connect your interfaces with implementations. If you have foo.cxx , everything defined in it was better declared in foo.h
• Ensure that each # header file includes all other necessary headers or forward declarations required for independent compilation.
• Resist the temptation to create an “all” headline. They always bother the road.
• Put a set of related (and interdependent) functions in a single file. Java and other environments encourage the use of one class for each file. With C ++, you often need one set of classes for each file. It depends on the structure of your code.
• Prefer forward declaration over #include when possible. This allows you to break the cyclic dependencies of the header. Essentially, for cyclic dependencies between individual files, you want the file dependency graph to look something like this:
  • A.cxx required Ah and Bh
  • B.cxx required Ah and Bh
  • Ah Bh required
  • Bh is independent (and forward-declares classes defined in Ah )

If your code is intended for a library consumed by other developers, the following additional steps must be taken:

• Use the concept of "private headers" if necessary. That is, the header files required by several source files, but never required by the public interface. It can be a file with common built-in functions, macros or internal constants.
• Separate your public interface from the private file system implementation. I usually use the include/ and src/ subdirectories in my C or C ++ projects, where include/ has all my public headers and src/ all my sources. and private headers.

I would recommend finding a copy of John Lakos's book, “Large-scale C ++ Software Development.” This is a pretty impressive book, but if you just look through some of your discussions on physical architecture, you will learn a lot.

Answer 2

Check out NASA's Goddard Space Coding Standards C and C ++. The only rule that I specifically noted in the C standard and which was adopted in my own code is one that provides a "stand-alone" nature of the header files. In the xxx.cpp implementation file for the xxx.h header, make sure xxx.h is the first header included. If the header is not self-contained at any time, compilation will fail. This is a beautiful and effective rule.

The only time it fails is if you port between machines, and the xxx.h header includes, say, <pqr.h> , but <pqr.h> requires funds that become available by the <abc.h> header on the original platform (therefore <pqr.h> includes <abc.h> ), but the tools are not available <abc.h> on another platform (they are in def.h instead, but <pqr.h> does not include <def.h> ). This is not a rule error, and the problem is more easily diagnosed and corrected if you follow the rule.

Answer 3

Check the header file section in the Google Style Guide

Answer 4

Tom's answer is great!

The only thing I would like to add is to never “use ads” in header files. They should only be allowed in implementation files, for example. foo.cpp .

The logic for this is well described in the excellent book Accelerated C ++ ( Amazon link - sanitized for script kiddie link nazis)

Answer 5

Another point in addition to the rest here:

Do not include any private definitions in the included file. For example. Any definition that is used only in xxx.cpp should be in xxx.cpp, not xxx.h.

It seems obvious, but I see it often.

Answer 6

I would like to add one very good practice (both in C and C ++) that often leaves:

foo.c

 #include "foo.h" // always the first directive 

Any other necessary headers should follow, followed by code. The fact is that you almost always need this header for this compilation unit in any case, including the first directive, ensuring that the header remains self-sufficient (if it is not, there will be errors). This is especially true for public headlines.

If at any time you need to put something before including the header (with the exception of the comments, of course), then most likely you are doing something wrong. If you really don’t know what you are doing ... which leads to another decisive rule => comment on your hacks!