Re: const has file scope
On May 3, 4:30 pm, "Phlip" <phlip2...@gmail.com> wrote:
pauldepstein wrote:
The C++ Primer (4th edition -- Lippman, Lajoie and Moo)
explains that (non-local) const variables have file scope
rather than global scope and can therefore be defined in
header files.
In this context, what is meant by a "const variable"? The
examples with (for example)
const int x = 2; are clear enough. But how about
references to const or non-const pointers to const int?
Do they have file scope (enabling inclusion in header files)
too? What exactly is this file scope rule?
The rule means: Given a header file "yo.h", you can write
these inside it, outside of any class:
const int x = 42;
static int y = 43;
Sure you can. If you do, you can't include the header in
multiple translation units, but that's a different issue.
For what it's worth, I have a couple of included files that do
contain such things. In this case, the use of an include is so
that I get different code, depending on the -I options passed to
the compiler (which in turn depends on the OS).
You cannot write a simple 'int z' because the linker would see
it twice, once per translation unit (combination of a .cpp
file and its included .h files).
I'm too lazy to check, but I don't think a diagnostic is
required in this case. (It wasn't in earliest C, and given the
way history lives on, it may not be today. All compilers I know
do give you one, however.)
The 'y' does not link, and each translation unit gets its own
private copy to change.
Changing 'x' causes undefined behavior, so a non-static const
at file scope has no meaning.
There's no such thing as file scope in C++. Perhaps you mean
namespace scope. In which case, I beg to differ:
#include <boost/array.hpp> // or simply <array> in C++0x
int const size = 43 ;
boost::array< int, size > array = { ... } ;
, for example. In fact, anything that uses the address of, or a
reference to the constant. (In many cases, it may just result
undefined behavior, rather than causing the code not to compile.
And in some of those cases, the resulting code will (seem to)
work.)
As a result, I've gradually been adopting the policy of
systematically using extern for all file scope variables.
(Note too:
int const i1 = 42 ;
enum { i2 = 42 } ;
inline void
f( std::vector< int >& dest )
{
dest.push_back( i1 ) ; // undefined behavior.
dest.push_back( i2 ) ; // no problem.
}
In practice, this is one case of undefined behavior I don't
worry too much about; I can't imagine an implementation where it
won't work in practice.)
Hence the language simply adds the effects of a 'static' for
you.
The rule was adopted a long, long time ago. It never really
made sense, but it didn't really cause any problems then, and
apparently, some programmers wouldn't use "int const" variables
in headers if they had to add the static. (My reaction would
have been to get rid of those programmers, but Bjarne is a more
tolerant than I am. A lot more tolerant.) Regretfully, it's an
idea that causes serious problems today, but changing the rule
would break far too much code to be feasible.
And compilers did not formerly apply this rule, so you will
find the 'static const' idiom in lots of legacy code...
Could you site one. It was present in the very first CFront
that made its way out of AT&T; it was present in the oldest g++
that I've used (1.49); and it was present in Zortech 1.0. (And
back then, those were the only C++ compilers in existance.) I'd
be very surprised if any compiler ever existed that didn't
implement it.
The presence of "static const" is probably due more to people
who favor legibility---say what you mean, and mean what you say.
And the rule only applies to the "top level" const. A pointer
to a const is itself a changable pointer. A const pointer to
const is not changable, but it will be tricky to initialize
correctly. (Different translation units initialize their
static and global variables in an undeterminable order.)
If the initialization is static, there should be no problem.
(On the other hand, I can't think of any use of a global const
pointer to const.)
A reference is already const, so it does not apply. Add the
static!
Curiously enough, that's not what the standard says. =A73.5/3: "A
name having namespace scope has internal linkage if it is the
name of [...] --- an object or reference that is explicitly
declared const and neither explicitly declared extern nor
previously declared to have external linkage; or [...]". Of
course, I'm not sure what "explicitly declared const" means in
the case of a reference:
int &const ri = i ;
is clearly illegal, and
int const& ri = i ;
declares the int referred to as const, not the reference.
It looks like a defect in the standard to me. (It could apply
to something like:
typedef int& CIR ;
CIR const ir = i ;
.. But I find it difficult to believe that the standard really
meant to say that the above has internal linkage.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34