Should I use one title to include all the static headers of the library?

Question

I have a static library that I create in C ++. I split it into many headers and source files. I am wondering if I need to include all the headers that the library client may need in one header file, which they, in turn, can include in their source code, or just include only those headers that they need? Will the code be overblown because of this? I was not sure that classes or functions that would not be used would still be compiled into their products.

Thanks for any help.

Answer 1

In general, when linking the final executable file, only characters and functions that are actually used by the program will be included. You pay only for what you use. At least how the GCC toolkit works for me. I can’t speak for all the tool chains.

If the client always has to include the same set of header files, I think that for convenience it will contain the "master" header file, which includes others. But make sure that the client can also choose only what is needed.

To reduce compilation time in large projects, in normal practice it is necessary to include the least number of headers in order to compile a unit.

Answer 2

how to do both options:

#include <library.hpp> // include everything #include <library/module.hpp> // only single module 

Thus, you do not have one huge include file, and for your individual files they neatly fold into one directory

Answer 3

It depends on the library and how you structured it. Remember that the header files for the library and which parts are in the header file are essentially part of the library API. Therefore, if you will attract your customers to carefully choose and choose among your headlines, you will need to maintain this layout for a long time. For libraries, it is often enough to export your entire interface through a single file or several files, if some part of the API is really optional and large.

Consideration should be compilation time: if the client must include two dozen files to use your library, and those that include internal ones can significantly increase compilation time in a large project if they are used frequently. If you go along this route, make sure that all of your included security features include not only the contents of the file, but also the inclusion lines. Although a note: modern GCC does a great job of dealing with this particular issue and requires only defenders around the contents of the header.

As for inflating the final compiled program, it depends on your tool chain and how you compiled the library, and not how the library client included the header files. (With the warning that if you declare static data objects in the headers, some systems will eventually contact the objects that define this data, even if the client does not use it.)

In general, if it is not a very large library, or a very old and confusing chain of tools, I would usually go with one inclusion. For me, freezing your current implementation section into headers in the library API is more worrying than others.

Answer 4

Keep in mind that every source file you compile includes an independent compiler call. With each call, the compiler must read the header file in each included file, parse it, and create a character table.

When you use one of these “include the world” header files in many source files, this can significantly affect build time.

There are ways to mitigate this; for example, Microsoft has a precompiled header function that essentially saves a character table for later compilation.

However, there is one more consideration. If I am going to use your WhizzoString class, I will not need to set the headers for SOAP, OpenGL and what you have. In fact, I would prefer WhizzoString.h to include only headers for types and characters that are part of the public interface (i.e. the Material that I will need as a user of your class).

As much as possible, you should try switching from WhizzoString.h to WhizzoString.cpp:

Ok

 // Only include the stuff needed for this class #include "foo.h" // Foo class #include "bar.h" // Bar class public class WhizzoString { private Foo m_Foo; private Bar * m_pBar; . . . } 

IT'S BETTER:

 // Only include the stuff needed by the users of this class #include "foo.h" // Foo class class Bar; // Forward declaration public class WhizzoString { private Foo m_Foo; private Bar * m_pBar; . . . } 

If users of your class never need to create or use a bar type, and the class does not contain any Bar instances, then it may be sufficient to provide only a direct Bar declaration in the header file (WhizzoString. Cpp will have #include "bar.h" ). This means that anyone, including WhizzoString.h, can avoid including Bar.h and everything it includes.