More questions about constants

1. There seem to be a number of opinions about how a const int (NOT a class member) should be declared & defined.

For example, in this thread
http://cboard.cprogramming.com/showt...ts+header+file
Elysia says "Don't put any variables in headers. Define them in a .cpp file and use extern in the header files."

In this one, Daved recommended defining a constant in a header file but enclosed in an unnamed namespace, ChaosEngine says to define it in a header file (wrapped in a #ifndef ... #endif block) as static const int, and CornedBee says that neither the static nor the namespace is necessary.
http://cboard.cprogramming.com/showt...nstants+header

I didn't find any clear statement on this from either Salem or Prelude. I'd love to get some further guidance on this -- is a consensus possible?


2. Sort of related to the above, does "static" have any significance in C++ when used OUTSIDE of any class definition? Is there any difference between a global "static const int x" vs. a global "const int x"?


3. This
http://www.parashift.com/c++-faq-lit....html#faq-29.7
sums up the reasons to prefer using const over #define, but it also says that there are cases when #define is preferable. So, when is #define preferable?

#define is the C version of a C++ constant. I would say the only time I would use #define is in a header file. I cannot find a reason why you would need to use it in a .cpp source file. constants more or less replaced #define in the C++ language when defining a variable to be constant ( read only ).

Every book I have read says #define on a variable is "evil" but that is their view not every single programmers. Just my two cents on the matter.

Quote:

---

Originally Posted by R.Stiltskin

For example, in this thread
http://cboard.cprogramming.com/showt...ts+header+file
Elysia says "Don't put any variables in headers. Define them in a .cpp file and use extern in the header files."

---

The reason I mentioned that is because you'll get linking errors if you put variables in headers directly.
There may be several approaches to this, but what I'd do is use define in a header or make the constants in a .cpp file and declare them as extern in the header files.
That way you avoid linking errors.

>> In this one, Daved recommended defining a constant in a header file but enclosed in an unnamed namespace.

Please note that I wasn't recommending doing that as a solution to the problem. I was merely stating that if you choose to make a static const int at namespace scope that you should use an unnamed namespace instead.

I'd trust CornedBee's recommendation to use neither static nor an unnamed namespace. I am not sure whether "extern" is required to avoid linking errors if you are declaring a constant.

>> 2. does "static" have any significance in C++ when used OUTSIDE of any class definition?
Yes. It means that the variable (or constant) is created for that particular compilation unit. If you put it in a source file, then functions in that source file can access it and you will not have any problems if there are similar names in other compilation units.

If you put it in a header file, it acts the same way, except it does so for each source file that includes that header (including the source files that include the header indirectly). This is why CornedBee mentioned that using static for a constant has the disadvantage of creating a duplicate for each source file that includes the header where it was declared.

Note that using static this way is deprecated in favor of an unnamed namespace, as I mentioned in the linked thread.

>> So, when is #define preferable?
I don't know of any situation where it would be preferable when a const variable or enum will also work. You can use #defines for pre-processor things like header include guards or conditional compilation.

Daved pointed out that "the use of the static keyword is deprecated when declaring objects in namespace scope", so that rules out ChaosEngine's suggestion. I note that the C++ Standard states in section 7.3.1.1: "The use of the static keyword is deprecated when declaring objects in a namespace scope (see annex D); the unnamed-namespace provides a superior alternative." This leads to Daved's suggestion, but I believe CornedBee is right: the unnamed/anonymous namespace means that there is a constant with the same name and value but in a different namespace in each file, thus it is duplicated across the program.

Consequently, I think that the use of extern as suggested by Elysia may be the best option, possibly when in a namespace. (At least excluding other options like enums and class members.)

Thanks to all of you.

I did some testing (not that I don't trust you guys) & it's clear that static in this context gives the variable file scope so when I put static int x in a header file & #include that header in 2 different source files, each source file gets a different variable named x whose value can be changed in one sourcefile & remain unchanged in the other. So, as laserlight & Daved said, putting a constant static const int x = 5 in a header & #including that in multiple source files results in multiple constants all named x with the value 5 & just wastes space (unless for some reason we want different variables named x with different values at different places in a program). I don't understand the point of an unnamed namespace -- static gives this behavior without any namespace in the code.

I also found that if the variable is not static, header include guards provide no protection (I thought they would); when I #include a header that defines int j = 8 in two different source files, g++ gives a "multiple definition" error. Thinking about it, the reason is obvious -- if that header is used to compile two separate object files it's going to create a separate global variable in each of them so clearly that creates a problem when it gets to the linker. I'm surprised I haven't had a problem with this before -- just lucky I guess.

So Elysia's solution seems to be the best since it avoids the compiler's multiple definition errors, allows selective inclusion in only the source files where the variable (constant or otherwise) is needed, and avoids using the "nasty" #define.

>> I don't understand the point of an unnamed namespace -- static gives this behavior without any namespace in the code.
And an unnamed namespace gives that behavior without any static in the code. The short answer is that you should prefer an unnamed namespace over static because the C++ standard tells you to. I don't know the long answer of why the standards committee made that decision without looking it up again. (Also remember that I'm only comparing instances where you will be using either static or an unnamed namespace, which is not the case in the example you are discussing in this thread).

>> I also found that if the variable is not static, header include guards provide no protection
A header include guard provides protection against compilation errors, since it stops a header from being included twice in the same compilation unit. It does not stop linker errors, since those come from the linker trying to combine the code in different compilation units.

The question I still have is whether the extern is necessary for constants.

Quote:

---

Originally Posted by Daved

The question I still have is whether the extern is necessary for constants.

---

It seems not to be. Actually, I have no trouble getting it to work without extern, and I was also able to compile with extern const int j declared in a header and defined in the "main" source file. But I can't figure out how to compile with the constant declared as extern in a header and defined in a separate source file. This set of files gives me two "undefined reference to 'j'" errors. (It compiles all 3 ".o" files, but doesn't link them.) Can you tell me what's wrong?

Code:

---

#ed: commented out the following 2 lines as they were not serving any purpose in this makefile
#CXX = g++
#CCFLAGS = -g -Wall

scopetest:        source1.o        source2.o        constants.o
        g++        source1.o        source2.o        constants.o        -o scopetest

source1.o:        header1.h        header2.h        source1.cc
        g++        -c        source1.cc

source2.o:        header1.h        header2.h        source2.cc
        g++    -c        source2.cc

constants.o:        constants.cc
        g++        -c        constants.cc

clean:
        rm *.o scopetest

---

Code:

---

// header1.h

#ifndef header1_h
#define header1_h

static int i = 4;
extern const int j;
//const int j = 6;

int dosomething();

#endif

---

Code:

---

// header2.h

namespace {
const int c = 5;
}

---

Code:

---

// source1.cc

#include "header1.h"
#include "header2.h"
#include <iostream>
using namespace std;

//const int j = 6;

int main() {
  dosomething();
  ++i;
  dosomething();
  cout << "in main, i = " << i << endl;
  cout << "in main, c = " << c << endl;
  cout << "in main, j = " << j << endl;
  dosomething();

}

---

Code:

---

// source2.cc

#include "header1.h"
#include "header2.h"
#include <iostream>
using namespace std;

int dosomething() {
  cout << "in source2.cc, i = " << i << endl;
  cout << "in source2.cc, c = " << c << endl;
  cout << "in source2.cc, j = " << j << endl;
  return i;
}

---

Code:

---

// constants.cc

const int j = 6;

---

Duh!

I needed #include "header1.h" in constants.cc. It should be

Code:

---

// constants.cc

#include "header1.h"

const int j = 6;

---

With that correction it compiles & runs correctly. Or, I can eliminate constants.cc and constants.o from the makefile and in header1.h replace

Code:

---

extern const int j;

---

with

Code:

---

const int j = 6;

---

and it compiles & runs correctly that way as well.

So, as Daved suggested, it seems that extern is not necessary for a constant.

Code:

---

// a1.cc
#include <iostream>

const int x = 5;

int main()
{
  std::cout << x << std::endl;
}

---

Code:

---

// a2.cc
const int x = 6;

---

Compile and link these two together.

1) Does you compiler/linker allow it?
2) If so, what value does it print?
3) Explain.
4) Add a function to a2.cc which prints x, and call that from a1.cc. What happens?

This exercise should help you figure out how C++ treats "const" at global scope.

The reason I suggest not making the constant extern is related to what brewbuck just posted. Basically, if the compiler can't see the value of the constant, it will have to treat it as a variable as far as the generated code is concerned. It's still a constant, but it's no longer a "constant expression", as the C++ standard calls it. That's the case in Elysia's way.
By making the value visible, the compiler can use it directly, use it in template instantiations, in array sizes, put it as a literal in the code, do compile-time partial calculations, loop unrolling, dead code elimination and all that jazz.

E.g.

Code:

---

// hdr.hpp
#ifndef HDR_H_SR_H
#define HDR_H_SR_H

extern int CON1;
const int CON2 = 0;

#endif

// src.cpp
#include <iostream>
#include "hdr.hpp"

int main()
{
  if(CON1) {
    std::cout << "Con1\n";
  }
  if(CON2) {
    std::cout << "Con2\n";
  }
}

---

The CON2 branch is optimized away by the compiler, the CON1 branch isn't.

Quote:

---

Originally Posted by CornedBee

Code:

---

// hdr.hpp
extern const int CON1;

---

---

How about extern const int. Regardless if it's in the current scope or not, the compiler can see that it's constant.

A typo in my test program. I just repeated it with the const, and the result is the same.
Of course, a compiler supporting whole-program optimization might discover this, too. Not all compilers do, though, and WPO is very expensive in compile time.

Nope. VC9 kills both for me. Even if it's "extern."

hmm... section 7.1.5.1 of the C++ Standard reads:

Quote:

---

An object declared in namespace scope with a const-qualified type has internal linkage unless it is explicitly declared extern or unless it was previously declared to have external linkage. A variable of nonvolatile const-qualified integral or enumeration type initialized by an integral constant expression can be used in integral constant expressions (5.19).

---

This confirms what CornedBee is talking about concerning "all that jazz". What I find interesting though is the mention of "internal linkage". Since I am not very clear on this concept, I checked out section 3.5:

Quote:

---

A program consists of one or more translation units (clause 2) linked together. A translation unit consists of a sequence of declarations.

Code:

---

translation-unit:
    declaration-seqopt

---

A name is said to have linkage when it might denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope:

• When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
• When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
• When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

A name having namespace scope (3.3.5) has internal linkage if it is the name of

• an object, reference, function or function template that is explicitly declared static or,
• an object or reference that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage; or
• a data member of an anonymous union.

---

So, without the extern the constant has internal linkage. Doesn't this mean that we have the same scenario as with static or the unnamed namespace where each source file (or more precisely, translation unit) has its own copy of the constant?

Yes, but all modern linkers perform constant folding, merging these into one.

And as I said, one is a const expression, the other not. Observe:

Code:

---

const int CON1 = 5;
extern const int CON2;

template <int I>
class foo
{
};

int main()
{
        int ar_yes[CON1];
        int ar_no[CON2];

        foo<CON1> t_yes;
        foo<CON2> t_no;
}

---

Code:

---

$ g++ -c -pedantic -std=c++98 src.cpp
src.cpp: In function ‘int main()’:
src.cpp:12: error: ISO C++ forbids variable-size array ‘ar_no’
src.cpp:15: error: ‘CON2’ is not a valid template argument for type ‘int’ because it is a non-constant expression
src.cpp:15: error: invalid type in declaration before ‘;’ token

---

The -std and -pedantic arguments are necessary to disable GCC's VLA for C++ extension.

Quote:

---

Originally Posted by brewbuck

...
Compile and link these two together.

1) Does you compiler/linker allow it?
No problem: g++ a1.cc a2.cc compiles & links them. (I'm using g++ 4.1.2.)
2) If so, what value does it print?
5
3) Explain.
It seems that each x has file scope.
4) Add a function to a2.cc which prints x, and call that from a1.cc. What happens?
My modified version of the program is below. When print() (in a2.cc) is called from main() it prints 6.

---

Code:

---

// a1.cc
#include <iostream>
extern void print();

//const int x = 5;
int x = 5;

int main()
{
  std::cout << x << std::endl;
  print();
}

// a2.cc
#include <iostream>

const int x = 6;
//int x = 6;
//extern int x;

void print() {
  std::cout << "print: " <<  x << std::endl;
}

---

I tried a few other variations: when I remove const from both definitions, I get a "multiple definition" error, even if a value is assigned in only one file. If either one of the xs is declared const, or if both of them are, then the program compiles/links without error and main() and print() each have their own (different) version of x so each x seems to have file scope.

The downside of having been taught not to use global variables is that I don't actually know how, but it seems that the only way to make a single (non-const) variable x global and accessible to all files is by using extern. Is this correct?

CornedBee:
I am still not sure what you are suggesting in the case of constants, but now it seems that defining them in a header file and including that in each source file that needs access to the constant is preferable because this method ensures that each such file has the same value assigned to its constant, it avoids the extern shortcomings that you pointed out, and, if I understand you correctly, the linker will merge multiple copies of a constant into one if they all have the same value, which they will. (Clearly, this does not happen when each file defines the same const symbol with a different value.)
Do you agree?

Quote:

---

Originally Posted by R.Stiltskin

Code:

---

extern void print();

---

---

That's not necessary. You can remove the extern for function declarations.

Quote:

---

The downside of having been taught not to use global variables is that I don't actually know how, but it seems that the only way to make a single (non-const) variable x global and accessible to all files is by using extern. Is this correct?

---

Yes, that is correct.

Quote:

---

...if I understand you correctly, the linker will merge multiple copies of a constant into one if they all have the same value, which they will. (Clearly, this does not happen when each file defines the same const symbol with a different value.)
Do you agree?

---

No, this is not always the case. Ponder the following output:

Quote:

---

Address of n is Help.cpp: 0040225C
Address of n in Help2.cpp: 0040223C

---

From this simple code:

Code:

---

// Help.h
const int n = 10;

// Help.cpp
#include "Help.h"
int main()
{
        cout << "Address of n is Help.cpp: " << &n << endl;
        Help();
}

// Help2.cpp
#include "Help.h"
void Help()
{
        cout << "Address of n in Help2.cpp: " << &n << endl;
}

---

So clearly, as you see, there are two variables with the same number, even in release.
Same goes even if it's static.
Same with an unnamed namespace.

Quote:

---

Originally Posted by Elysia

No, this is not always the case. Ponder the following output:


From this simple code:

Code:

---

// Help.h
const int n = 10;

// Help.cpp
#include "Help.h"
int main()
{
        cout << "Address of n is Help.cpp: " << &n << endl;
        Help();
}

// Help2.cpp
#include "Help.h"
void Help()
{
        cout << "Address of n in Help2.cpp: " << &n << endl;
}

---

So clearly, as you see, there are two variables with the same number, even in release.
Same goes even if it's static.
Same with an unnamed namespace.

---

Have you considered that the very act of taking the address could be what is preventing the folding from occurring? Given that the address is the only observable difference between the constants, taking it would make the folding observable, and thus prevent it from occurring. Just a thought.

Very quantum.

I don't see how you got that to run without <iostream> and std:: for cout & endl, but with those modifications, yes, g++ 4.1.2 also ends up with 2 different addresses for n, so this seems to contradict CornedBee's statement.

Here is the only way that I have found so far that produces a single global constant (a single address) defined in a separate file:

Code:

---

// Help.h
extern const int n;

// Help.cpp
#include "Help.h"
#include <iostream>

void Help();

int main()
{
  std::cout << "Address of n is Help.cpp: " << &n << std::endl;
  Help();
}

// Help2.cpp
#include "Help.h"
#include <iostream>

void Help()
{
  std::cout << "Address of n in Help2.cpp: " << &n << std::endl;
}


//Help3.cpp
// this file can contain all constant definitions

#include "Help.h"

const int n = 10;

---

ed: I didn't see CornedBee's last post until after I posted this one. Re the "quantum" comment, it's an interesting thought, but what are we to make of that? i.e. How can one rely on a compiler to behave a certain way, when attempting to verify it results in different behavior? In short, do you recommend following the approach I stated in the last paragraph of #17?

Quote:

---

How can one rely on a compiler to behave a certain way, when attempting to verify it results in different behavior?

---

Suppose that CornedBee says is true (and it might be). Does silently folding the constants affect the behaviour of the code? No, it does not, so it is safe. Only when it is unsafe then it is not done, so it does not matter when it is safe.

Another thought: constant folding is done by the compiler, not the linker, right? If I understand correctly, each of the .cc and .cpp files in our examples is a separate compilation unit, and if so, why would we expect constants defined in separate files to be merged?

Quote:

---

Another thought: constant folding is done by the compiler, not the linker, right?

---

In this case it would be performed by the linker, if it is done at all. Other types of constant folding (e.g., evaluating constant arithmetic expressions or substituting constant expressions) would be done by the compiler.

Quote:

---

Originally Posted by laserlight

Suppose that CornedBee says is true (and it might be). Does silently folding the constants affect the behaviour of the code? No, it does not, so it is safe. Only when it is unsafe then it is not done, so it does not matter when it is safe.

---

I think that even before CornedBee brought us into Schroedinger's world, this discussion had become more theoretical than practical. I agree that in most cases the extra memory consumed by having multiple copies of some constants may be trivial. The question is, is it necessary?

Quote:

---

Originally Posted by R.Stiltskin

i.e. How can one rely on a compiler to behave a certain way, when attempting to verify it results in different behavior?

---

It is perfectly well-defined behavior. "const" tells the compiler it is allowed to fold the constant when possible. If it is declared "extern," it cannot fold the constant because it has been explicitly declared to reside elsewhere. And if you take the address of a constant, this also forces the compiler to create an actual variable so that it can have an address.

The change in semantics of "const" in C++ was meant to DISCOURAGE the use of #define. You were supposed to be able to replace a #define with a const declaration, even in a header file. In other words, the "new const" was meant to act very much like a #define replacement. The examples given here show that declaring a global/namespace const variable in a header file is usually okay, because we don't typically take the address of a simple constant or use "extern."

Maybe it's confusing, but the comparison with quantum physics was meant partially in jest (I assume) -- there's no random behavior here, you just have to understand it.

Quote:

---

Originally Posted by R.Stiltskin

Another thought: constant folding is done by the compiler, not the linker, right? If I understand correctly, each of the .cc and .cpp files in our examples is a separate compilation unit, and if so, why would we expect constants defined in separate files to be merged?

---

The linker can fold as well. It does so whenever it throws out duplicate template instantiations. Also, most link and executable formats have the concept of a "weak symbol" which can be defined in multiple modules -- all the definitions are merged into one during link time. In the past when linkers did not support such folding, there were complicated pre-link steps required to weed out multiple template instantiations, or other compiler-specific weirdness to get it to work.

However, as we've already shown here, most const definitions don't even get created as actual symbols in the object code. Unless they are declared "extern" or you take their address, that is.

I think the quantum reference was that by simply attempting to observe the behavior you are changing it.

I guess the bottom line is that simply creating a constant variable in a header is generally the best option, there is no need for extern, static or an unnamed namespace.

Quote:

---

Originally Posted by Daved

I think the quantum reference was that by simply attempting to observe the behavior you are changing it.

I guess the bottom line is that simply creating a constant variable in a header is generally the best option, there is no need for extern, static or an unnamed namespace.

---

I'll be happy to take that as the final answer, unless others object...

Quote:

---

I guess the bottom line is that simply creating a constant variable in a header is generally the best option, there is no need for extern, static or an unnamed namespace.

---

I agree, since it appears that the extern version is a minor optimisation that may already be done by the linker.

Quote:

---

Originally Posted by R.Stiltskin

I don't see how you got that to run without <iostream> and std:: for cout & endl, but with those modifications, yes, g++ 4.1.2 also ends up with 2 different addresses for n, so this seems to contradict CornedBee's statement.

---

I left that out.
The "real" code would be, for Help2.cpp:

Code:

---

#include "stdafx.h"
//#include <Stuff/NewThread.h>
#include "Help.h"

using namespace std;

void Help()
{
        cout << "Address of n in Help2.cpp: " << &n << endl;
}

---

Quote:

---

Originally Posted by CornedBee

Have you considered that the very act of taking the address could be what is preventing the folding from occurring? Given that the address is the only observable difference between the constants, taking it would make the folding observable, and thus prevent it from occurring. Just a thought.

Very quantum.

---

Then what do you propose to find out if there's one or multiple constant variables?
Even with assembly, there will still be two copies.

You could disassemble the executable. But what for? To find out whether you have 4 more bytes in the static section?

Here's something you can try with only generating assembly:

Code:

---

#include <iostream>

const int CON = 100;

int main()
{
        std::cout << CON << '\n';
}

---

Enable optimizations and find CON in the assembly output. (I tried this with GCC 3.4.4 and -O2)

As long as you treat constants as constants and not as variables (e.g. take the address), they won't even be emitted. Size requirement: zero. Whereas if they're extern, they always need the space.

It's not so much practical effort, it's just that I want to know.