global const variable being local to a file by default

[subramanian100in]

I read in C++ Primer 4th Edition by Stanley Lippman, in page 57, that
const variables at global scope are local to a file by default.

What is the advantage of this rule ?

Suppose I have the following const variable defined in a.h

const int const_int = fn();

Suppose a.h is #included in a.cpp which also contains the following
function.

int fn()
{
static int counter;
return ++counter;
}

Assume a.cpp uses the variable 'const_int'. Suppose a.h is #included
in another file b.cpp which uses 'const_int'

We will get different values for the const int variable 'const_int'
when it is used in these two files. Am I correct ? This situation
arises because the compiler allows a non-const expression to be used
as the initializer for the const variable and yet it allows the const
variable to be available local to the files.

Why doesn't the compiler DISALLOW this ? ie If the compiler disallows
a const variable to be defined in multiple .cpp files, this will not
arise.

Please correct me wherever I have gone wrong.

Kindly explain.

Thanks
V.Subramanian

 

[asterisc]

I read in C++ Primer 4th Edition by Stanley Lippman, in page 57, that
const variables at global scope are local to a file by default.

What is the advantage of this rule ?

Suppose I have the following const variable defined in a.h

const int const_int = fn();

Suppose a.h is #included in a.cpp which also contains the following
function.

int fn()
{
static int counter;
return ++counter;

}

Assume a.cpp uses the variable 'const_int'. Suppose a.h is #included
in another file b.cpp which uses 'const_int'

We will get different values for the const int variable 'const_int'
when it is used in these two files. Am I correct ? This situation
arises because the compiler allows a non-const expression to be used
as the initializer for the const variable and yet it allows the const
variable to be available local to the files.

Why doesn't the compiler DISALLOW this ? ie If the compiler disallows
a const variable to be defined in multiple .cpp files, this will not
arise.

Please correct me wherever I have gone wrong.

Kindly explain.

Thanks
V.Subramanian

You can't have two fn() defined in two different cpp files and still
link them in one executable files...

 

[Matthias Buelow]

What is the advantage of this rule ?

I can't see any; if you want it local, use "static" (where you'll have
the same problems, btw. But at least "static" is a well-known idiom for
that).

Suppose I have the following const variable defined in a.h

[...]

Yes, this is indeed a problem. To avoid this, don't use non-constant
expressions to initialize a constant.

Why doesn't the compiler DISALLOW this ? ie If the compiler disallows

Perhaps there are situations where such behaviour might be desired. I
would strongly advise against creating such situations, since it is a
tricky issue and usually also dependent on link order (very bad).

The following example illustrates the issue:

-----tt1.cc-----
#include <iostream>

using namespace std;

#include "tt.h"

int fn()
{
static int counter;
return ++counter;
}

int main()
{
extern int get_the_other_one();
std::cout << const_int << '\n';
std::cout << get_the_other_one() << '\n';
return 0;
}

-----tt2.cc-----
#include "tt.h"

int get_the_other_one()
{
return const_int;
}

-----tt.h-----
extern int fn();

const int const_int = fn();
----------

$ c++ tt1.cc tt2.cc
$ ./a.out
2
1

$ c++ tt2.cc tt1.cc
$ ./a.out
1
2

 

[James Kanze]

I read in C++ Primer 4th Edition by Stanley Lippman, in page 57, that
const variables at global scope are local to a file by default.

What is the advantage of this rule ?

To confuse people, and frustrate programmers. It's obviously a
mistake, but for whatever reasons, it's there, and it can't be
changed at this late date.

Suppose I have the following const variable defined in a.h

const int const_int = fn();

Suppose a.h is #included in a.cpp which also contains the following
function.

int fn()
{
static int counter;
return ++counter;
}

Assume a.cpp uses the variable 'const_int'. Suppose a.h is #included
in another file b.cpp which uses 'const_int'

We will get different values for the const int variable 'const_int'
when it is used in these two files. Am I correct ?

You have two different variables, with two different values,
yes. If you only want one, then you have to declare:

extern int const const_int ;

in the header, and:

extern int const const_int = fn() ;

in one (and only one) source file.

Which, by the way, might explain why the rule is there. Here,
it's not an issue, because the initialization expression is not
const itself, but if you want to use the variable as a compile
time constant (integral constant expression), then the compiler
has to see the initializer. Which means that the initializer
must be present in the header, which means that the header must
contain a definition, not a declaration, which means that if it
doesn't have internal linkage, you have a violation of the one
definition rule.

There are other ways around this; the way static const is
handled in a class, for example. But they also cause some
confusion, and I don't think that the compiler technology in the
early days of C++ would have easily supported them.

This situation arises because the compiler allows a non-const
expression to be used as the initializer for the const
variable and yet it allows the const variable to be available
local to the files.

Why doesn't the compiler DISALLOW this ? ie If the compiler
disallows a const variable to be defined in multiple .cpp
files, this will not arise.

I think you mean "if the compiler allowed a const variable to be
defined in multiple source files". It does, in the case of
static members, but that's very much an exception. And I'm not
sure that the technology to support this was available in the
early days.

 

[subramanian100in]

To confuse people, and frustrate programmers. It's obviously a
mistake, but for whatever reasons, it's there, and it can't be
changed at this late date.

As a help I am asking the following question:

If the above question(and also similar questions where some peculiar
situation is present in the standard itself) is asked in the
interview, what is your advise to me to answer the interviewer. In
real application I will not use the above situation.

Kindly clarify.

Thanks
V.Subramanian

 

[Alf P. Steinbach]

* (e-mail address removed), India:

As a help I am asking the following question:

If the above question(and also similar questions where some peculiar
situation is present in the standard itself) is asked in the
interview, what is your advise to me to answer the interviewer. In
real application I will not use the above situation.

Kindly clarify.

You can answer that it's less to write for the most common case.

Cheers, & hth.,

- Alf

 

[James Kanze]

* (e-mail address removed), India:

You can answer that it's less to write for the most common case.

Actually, I'd answer that I don't want the job. Any place
asking questions that stupid isn't a place I want to work for.
(I don't think the amount you have to write was an actual
consideration when the rule was formulated, but it may have
been, and it's as good a (non-)reason as anything else.)

Of course, questions designed to determine whether the candidate
knows this particular rule, and more generally, whether he knows
the rules for determining linkage (which are far from trivial)
are fair game.