Source Clean-up Question

Question

I have source that has been around for 10 years old in C++. It works on OS X, Linux and Windows well. It is a static Library of API calls other developers might need to use.

Over time, previous programmers have sort of not kept it tidy.

So my question:

There are several headers that most sources use. I could put them all in a single header and update the source files to use that instead of them all including each one every time. Wise move?

Second, would it be wise to include all the DEFINEs in header and just include that versus a few defines in each header?

Third, if I do a single header that has all the .h's that are common every time, can I then put things like #pragma once and not have to do it in each header as well.

Fourth, same would apply for all the times we call if (Mac) #include just put in in the one header and include that one header where needed versus each header calling Carbon.h

I hope that my organization/optimization questions make sense. I would like to better understand optimizing...

Answer 1

Simple answer:

No to all of these, some object files may not need certain headers. All you're really doing is introducing bad practice and increasing compile time.

Answer 2

I would avoid creating a single header file that has additional header files. It just gets hard to keep track of where everything is if you do things like that. The one cleanup that makes sense is having one #include in the .cpp file(to that file's .h file). All other #include directives should be in one place in the .h file.

I am all for being DRY but in this case you can actually hurt productivity when you have to search around to figure out what includes are being included for a file. Also includes are not like code where it will be changing very much. It is either there or it isn't, so simply consolidating the location doesn't really buy you much, and in addition, you can be including more than you need for some files(which will slow the compile a bit).

Perhaps try eliminating includes that aren't needed anymore, or making code more readable. I think your time is better spent cleaning up the code, rather than fretting about includes. I have never found myself getting frustrated with the organization of includes, but bad code can definitely ruin your day!

Answer 3

Rearranging headers has no effect on performance, but it does affect compile-time. The more files have to be parsed in a translation unit, the longer it will take to compile.

So if you bundle all your headers into a few "master headers", you end up including more than necessary, and more than you would otherwise -- performance will be unchanged, but compiles will take longer.

Answer 4

There are several headers that most sources use. I could put them all in a single header and update the source files to use that instead of them all including each one every time. Wise move?

It depends what you're trying to optimize.

It's wise because:

• Simpler source code (single header per project instead of different headers for each source file)
• Therefore more maintainable

On the other han it's unwise because:

• Compile-time increases (some CPP files shouldn't need to compile every header file), unless you're using precompiled headers)
• Harder to extract a single CPP file and use it in a different project (because the CPP file is using a project-specific header file, instead of the minimal set of header files which it needs)

Second, would it be wise to include all the DEFINEs in header and just include that versus a few defines in each header?

Maybe yes, to ensure that the #defines are set consistently thoughout the project? Even better would be to define them in the project-file/makefile (passed to the compiler via the command-line), so that they're the same for every CPP file.

Third, if I do a single header that has all the .h's that are common every time, can I then put things like #pragma once and not have to do it in each header as well.

There's a book that covers many of these details: Large-Scale C++ Software Design by Lakos.