# Using Constants in Headers

This topic is 1882 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello,

I have been running into a problem in my code lately. I have a file called "Constants.h" and one called "Constants.cpp." I define all my constants there. However, when I include Constants.h in another .h file I always get compile errors when, for example, trying to allocate arrays of a GIVEN_CONSTANT size. Is there a reason for this? I never get these errors in .cpp files. It seems like the pre-processor is not expanding my #includes into the header, or maybe there is a rule that constants can't be used in headers in c++? Can someone shed some light on this situation for me?

Thanks.

- Dave Ottley

##### Share on other sites
It would help to see what your code actually looks like and what compiler errors you're actually getting.

##### Share on other sites
I'll give you an example. This is not exact because I have already fixed the errors with a workaround. But, for example

Constants.h:
extern const int MAX_INTS;

Constants.cpp
extern const int MAX_INTS = 1000;

Foo.h
#include "Constants.h"
class Foo {
int bar[MAX_INTS];
void DoSomething();
};

Compiler Error: "Arrays must be initialized with a constant."

*NEW* Foo.h
#include "Constants.h"
const int MAX_INTS = 1000;
class Foo {
int bar[MAX_INTS];
void DoSomething();
};

Compiles fine. Edited by KingofNoobs

##### Share on other sites
Why aren't you putting the constants in the header?

##### Share on other sites
First of all, in your Constants.cpp file you need to write "const int MAX_INTS = 1000; "
The extern keyword means "declare without defining". In other words, it is a way to explicitly declare a variable, or to force a declaration without a definition.

The practice itself (putting the initialization into the cpp file) is a matter of personal taste. I personally like it because if i need to change the value for whatever reason, not every single file which includes the header file is compiled again.

But i wouldnt use "extern" anymore....i like static const uint32 MAX_INTS; in a header file more. ;-)

##### Share on other sites
. Edited by C0lumbo

##### Share on other sites
Thank you all for your comments. I have decided to go with the

#ifndef
#define MAX_INTS 1000
#endif

route because it doesnt waste any memory. I cant see a downside to it either, and this is how the Microsoft .h files are organized. Until next time...

- Dave Ottley

##### Share on other sites
... and this is how the Microsoft .h files are organized.

*Cringe*

The windows headers aren't exactly the pinnacle of clean non-namespace-polluting headers...

##### Share on other sites
You really got the wrong conclusion from this. You don't know if using a const variable wastes any memory, so that's a terrible reason to pick one over the other. An optimized build with g++ generates identical code for both.

A const variable behaves like any other variable, while a macro constant has surprises: you can't take its address, it doesn't have a namespace, it doesn't obey the usual scoping rules, you can't access its value from a debugger, it can't be an object of a class...

You should write your code to be as clear as possible, minimizing surprises, not whether you might save 4 bytes (which you won't anyway). And therefore you should prefer using const variables over macros to represent constants.

##### Share on other sites
Alvaro,

Thank you for that additional input. Could you possibly link or attach an example of a (if possible complex) header defining const variables that use the features you list above such as namespaces, being objects in classes, having their addresses taken, etc. I guess I need to see what kind of complexity doing this entails, and if I will ever use those features.

-Dave Ottley

##### Share on other sites
The code in the header file would look exactly as I posted above, except for possibly being in a namespace. But if you aren't using namespaces [yet], there is no point in putting this particular thing in a namespace.

I can't post any code from work, but we do this type of thing all the time there.

Just test to print the value of the constant from a debugger, and you'll immediately see one of the benefits of using a const variable.

##### Share on other sites
Keep in mind that the MS windows headers are designed to be used from C as well as C++. So while there are (reasonably) good reasons for what they do in their code, you should only copy them if you are working under the same kind of constraint.

Also, for integral constants, another option is using an enum. Like a #define it never occupies storage, but like const variables it respects scope.

##### Share on other sites
If I have a const string I access from several places, should I declare it extern and move definition to a .cpp or make it static? Since just making it const string in the header would create multiple objects?

##### Share on other sites
That's not something you really need to worry about. Most linkers will fold identical constant data (including strings) into a single instance. Ex: MSVC's /opt:icf behavior.

##### Share on other sites
Thank you all for your kind responses. So, should I put a namespace i.e. Constants:: around my constants, or would that be a waste of keystrokes?

##### Share on other sites
Unless your constants have some sort of logical reason that they should be either grouped together or sectioned off from other symbols, then there's no point in creating a namespace just for constants. For example, you might group constants that form flags together or constants for private use separate from other symbols. But there's no point to dumping all your constants in a namespace just to have a namespace.

##### Share on other sites

So, should I put a namespace i.e. Constants:: around my constants, or would that be a waste of keystrokes?

A good rule of thumb, I think, is to put each constant in the same namespace as the subsystem/library/... it's associated with e.g.

 // hypothetical example namespace render { const float max_fov_degrees = 179.0F; class camera { // ... }; } // render 

Putting all constants in the entire application in a single namespace feels to me like an attempt to cut concerns along an unusual axis.