C++: What to do with all these classes

  • Context: C/C++ 
  • Thread starter Thread starter Saladsamurai
  • Start date Start date
  • Tags Tags
    Classes
Join the discussion
Ask a follow-up here, or get your own question answered by working scientists, mathematicians and engineers — people, not an autocomplete.
Real named experts · corrections over time · the nuance an AI answer skips
5 replies · 3K views
Saladsamurai
Messages
3,009
Reaction score
7
I am wondering, after one has created a bunch of header and implementation files for a bunch of related classes, what do you do with them? How can they be organized so that I do not have to #include " " an unreasonable amount of headers in different programs? I am googling this, but I am not quite sure what it is that I am looking for.

Thanks!
 
on Phys.org
I would compile them into a library file which you can link in whenever needed.
 
Code:
//file group_header.hpp
#ifndef GROUP_HEADER_NAME_GOES_HERE
#define GROUP_HEADER_NAME_GOES_HERE

//multiple headers included here
#include "header1.hpp"
#include <header2>
#include "header3.h"
//etc

#endif

Code:
//file main.cpp
#include "group_header.hpp"

int main() {}
 
You can have one #include "everything.h" that has #includes for all your other .h files.
 
Having a kitchensink.h or whole_enchilada.h is almost always a very bad idea. When I'm browsing through a package and see such a monster I take that as a sign of a poorly designed chunk of software.

Much better is to make your header files include the header files that are needed by that header. Example: Suppose file bar.h defines the class Bar, one of whose data members is of type Foo. Class Foo is defined in the file foo.h. In this case, the file bar.h should contain a #include "foo.h" directive. On the other hand, if the dependencies to class Foo in bar.h are only in the form of pointers or references to instances of Foo, then bar.h should not #include foo.h. All that is needed is a forward declaration of the class. In your source files, you should include only the headers that define the external functionality needed by that source file. You should not have to include the headers needed by those headers if you developed your header files correctly.

What if you need to include dozens and dozens of header files in a single file? That too is a sign of a bad design. It's called excessive fan-out. A fan-out of more than 7±21[/color] is a sign of problems. A fan-out in the dozens is a sign of big problems.1[/color]George Miller, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", Psychological Review 63 (2): 81–97 (1956).
 
zhermes said:
I would compile them into a library file which you can link in whenever needed.

What does that have to do with the 'headers' question?

Coin said:
You can have one #include "everything.h" that has #includes for all your other .h files.

You are unnecessarily increasing your build times. If you change even one header file, the whole project would be rebuilt even in incremental builds.