将const放在标题中

Question

From everything I am reading and testing, there is no way (without a preprocessor macro) to define a constant in a shared header and ensure that each TU is not creating its own storage for that constant.

I can do this:

const int maxtt=888888;

Which is the same exactly as:

static const int maxtt=888888;

And if this header is shared, it will work but each TU gets its own copy of maxtt . I could also do this, to prevent that:

extern const int maxtt;

But then I cannot define maxtt here; that must be done in a CPP to avoid linker error.

Is my understanding correct?

Answer 1

Since the variable is constant, the fact that each TU gets its own copy is usually irrelevant.

In C++, constants at namespace scope are implicitly static for this reason. Often this allows for better code than if you only had a single instance with external linkage, since (if the variable is actually a constant expression) the constant can often be folded right into the usage site and doesn't need to be stored at all.

So unless you really need to take the address of the constant, or something like that, you should stick with the static version. (And as you already observed, you can force external linkage by adding extern .) Another reason may be that you're initializing dynamically and only want one call to the initializer:

// header:
extern int const n;

// one implementation:
int const n = init_function_with_side_effects();

The static construction ( int const n = init(); in the header) would cause the function to be called once in every TU.

Answer 2

You write,

“From everything I am reading and testing, there is no way (without a preprocessor macro) to define a constant in a shared header and ensure that each TU is not creating its own storage for that constant.”

Happily that's incorrect .

For a small integral value you can always just use an enum . The trade-off is that you can't pass the address of an enum value, because it has no address. It's pure value.

However, saving space for an integral value is a pretty meaningless thing to do, since it's so small.

So, let's consider a biggie thingy,

struct BiggyThingy
{
    unsigned char zeroes[1000000];
    BiggyThingy(): zeroes() {}
};

Now how can we declare a BiggyThingy constant in a header file and ensure a single one overall for the whole program?

Using an inline function.

Well the simplest is this:

inline BiggyThingy const& getBiggyThingy()
{
    static BiggyThingy const theThingy;
    return theThingy;
}

static BiggyThingy const& biggyThingy = getBiggyThingy();

If you don't want a reference taking up space (like a pointer) in each translation unit, then just use the function without the notation-simplifying reference.

Using the template constant trick.

Here is another way to provide the constant, leveraging a special rule for templates instead:

template< class Dummy >
class BiggyThingyConstant_
{
public:
    static BiggyThingy const value;
};

template< class Dummy >
BiggyThingy const BiggyThingyConstant_<Dummy>::value;

typedef BiggyThingyConstant_<void> BiggyThingyConstant;

which can be accessed like

foo( BiggyThingyConstant::value )

Or if you want nicer notation you can add a reference per translation unit, as for the inline function solution.

Disclaimer:

Code untouched by compiler.

But you get the ideas, I think. ;-)

Answer 3

This code generates a constant in the TU only if you apply any operation that requires the address of the constant.

static int maxtt = 888888;
int * pmaxtt = &maxtt; //address of constant requested.

This may work as well and avoids the linker problem (though it'll store maxtt in each TU if the address is requested):

constexpr int maxtt = 888888;

Avoid the extern construction as it can't be optimized.

Answer 4

If you're so worried about storage, use an enumeration:

enum { maxtt = 888888 };

Enumerators are scalar rvalues and hence do not require storage. It is illegal to say &maxtt .

Answer 5

Indeed, your understanding of the semantics are correct.

In practice, each translation unit might not get a copy of the storage for the integer. One reason is that the compiler might implement the value as a literal wherever it is referenced. The linker might also be smart enough to discard the storage if it finds it isn't referenced.

The compiler might not be free to use a literal for your constant. You might take a reference to that integer, or get a pointer to it. In that case, you need the storage -- and you might even need the cross-compiland uniqueness. If you take the address of your const symbol in each compilation unit, you might find that its different since each object will get a unique, static copy.

You might have a similar problem if you use an enum; your const int has storage, and you can take the address of that storage. You can't take the address of an enumerand until you store it someplace.