Thread: More questions about constants

#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.

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.

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.)

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;

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.

Originally Posted by R.Stiltskin

Code:

extern void print();

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

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.

...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:

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.

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.

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;
}

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.

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?