What's the point of creating a header file with extern declarations?

Question

So I've been looking into cleaning up my code, and found suggestions about defining global constants (char const* strings for example) in a separate cpp file, with a header declaring them extern. Then you can include the header wherever you need it, and have access to the variables from a single location.

For example

strings.hpp

extern char const* strA;
extern char const* strB;

strings.cpp

#include "strings.hpp"

char const* strA = "strA";    
char const* strB = "strB";

This made sense, I thought, but after a bit it occurred to me that this is going to cause needless recompilation of large chunks of the project. If I keep all my strings together, for example, whenever I add a new string I have to modify the header. That means that every cpp file that includes that header is going to be recompiled. As a project grows in complexity, this can add up, though I'm not sure if it would be a lot of time.

It seems to me that a solution to this problem would be to keep the idea, but instead of including the header, declare and define the constants in one cpp file:

strings.cpp

extern char const* strA;
extern char const* strB;

char const* strA = "strA";    
char const* strB = "strB";

Then in any file that needs the strings, I declare the required variables

A.cpp

extern char const* strA;

B.cpp

extern char const* strB;

Essentially, manually doing what the include would have done for me.

With the difference that if I later need to add a char const* strC, used in C.cpp, I add the extern declaration and definition in strings.cpp, declare it again in C.cpp, and A.cpp and B.cpp don't need to be recompiled.

The downside to this approach is code duplication. Instead of declaring the variable once and including the declaration, I have to declare every variable anywhere I want to use it. The problem with that would be that if I decide to rename the variable, I have to rename it in several places. But then again, if I rename a variable I'd have to modify all the files that use it anyway, even if the declaration was included. And I can just do a global rename anyway.

It seems like the cost in time of recompiling several source files when making changes that don't affect them can grow much larger than the cost of renaming variables you may or may not modify. And yet, I've never seen this downside to the included declaration header mentioned.

Is there anything I am missing?

Answer 1

If you change a string you only need to recompile that one file. It's expensive to add a string but very cheap to modify a string. The other benefit is that all your strings are in the one place. If you decide you would like to change one you don't have to go searching through many files for it or if you want to translate your program it's easier.

If you have many strings spread throughout your project perhaps group them rather than have them all in the same header. Also remember that if you don't use any of them, don't include that header.

Answer 2

Including the same header in multiple files ensures that the same declaration is seen by every source file that uses the identifier. This reduces errors.

If there are various subsets of the declarations that are used and not used by various source files, then the declarations can be partitioned into multiple headers, Ah , Bh , Ch , and each header will be included only the source files that use its declarations. Then, when a declaration is changed in Bh , source files that include Ah or Ch but not Bh do not need to be recompiled.

To some extent, yes, there is some needless recompilation because sometimes a declaration changes in a header, resulting in compilation of a source file that uses the header but not the declaration that changed. This is generally regarded as a small cost for the benefit of avoiding the errors and complications caused by duplicated code.