user2620089
user2620089

Reputation:

Is it possible to package C++ libraries?

I know in C++ you have to use the "#include" statement to include libraries and headers, like:

#include <iostream>
#include <string>

#include "my_header.h"

But after some time, that can look very ugly, having a load of includes in your files. I wanted to know if there is some way where we can call just 1 file to include EVERYTHING we'll need in the C++ project. Kind of like...

"include_everything.h"

#include <iostream>
#include <string>

#include "header1.h"
#include "header2.h"

and then in our .cpp file, could we go?

#include "include_everything.h"

// write code here...

If it is possible, is it lawful? Does it abide by the C++ coding laws?

Thanks in advance, Gumptastic

Upvotes: 0

Views: 229

Answers (3)

Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385144

Yes, you can do it. You may recursively include headers.

However, If you are including so many headers that this is a problem, either you're including ithings you don't need to include or your source files are way too expansive.

Consequently, it's very rare to do this and I'd go so far as to consider it a big code smell. The only time you really want to do it is when you're going to precompile that include_everything.h.

Upvotes: 0

LawfulEvil
LawfulEvil

Reputation: 2337

If that is the only rule you decide not to follow you will probably be fine. But, depending on what some of those headers contain (macros, #defines, etc) you could get a horrible mess in the end.

I've seen cases where people included what they thought they needed (often ended up being much more than was needed as they failed to consider forward declarations). On a large software project, each CPP file ended up loading nearly every include file anyway (due to chaining). Often the same file would get loaded multiple time and only excluded once the #ifndef statement at the top was triggered. The OS ended up opening over 100k files for each compile even though only there were only 50k files in the project. In a horrible situation like that it might help.

It can save time for developers as they, generally, won't have to search out where something is defined and add it to their include list for every file they work on. Do it once and forget. Let the compiler tell you if a new file needs to be added to 'everything'.

Aside from the macro problem you might run into issues with overlapping names and such if you don't properly use namespaces. Also, template classes often have real code in the header file. This can create churn.

It might also cause problems if people are using global variables and they are eclipsing local variables. It might be hard to figure out where that global 'i' is defined and being pulled in from if you have to search all files in 'everything' instead of just the files in your include list.

You can do it. If its just you and includes bug you, go for it. If you are your buds are doing something, sure. You are going to serious looks from people if you try to do this on a medium sized project or larger.

At best, I wouldn't suggest using to go beyond grouping tightly bundled headers together into a more coherent API.

Upvotes: 1

Philipp
Philipp

Reputation: 69663

You can do this, but it might affect compilation time.

The C(++) #include compiler instruction means nothing more than "Before you compile, copy and paste the content of that file here". That means when you include more headers than necessary, it will take a bit longer to compile each source file. But when that's not a concern for you, go ahead.

Upvotes: 0

Related Questions