tags:

views:

7150

answers:

10

When refactoring away some #defines I came across declarations similar to the following in a C++ header file:

static const unsigned int VAL = 42;
const unsigned int ANOTHER_VAL = 37;

The question is, what difference, if any, will the static make? Note that multiple inclusion of the headers isn't possible due to the classic #ifndef HEADER #define HEADER #endif trick (if that matters).

Does the static mean only one copy of VAL is created, in case the header is included by more than one source file?

A: 

Static prevents another compilation unit from externing that variable so that the compiler can just "inline" the variable's value where it is used and not create memory storage for it.

In your second example, the compiler cannot assume that some other source file won't extern it, so it must actually store that value in memory somewhere.

Jim Buck
A: 

Static prevents the compiler from adding multiple instances. This becomes less important with #ifndef protection, but assuming the header is included in two seperate libraries, and the application is linked, two instances would be included.

Dan Pieczynski
+5  A: 

No. The static means that there will be one copy of VAL created for each source file it is included in. But it also means that multiple inclusions will not result in multiple definitions of VAL that will collide at link time. Without the static you would need to insure that only one source file defined VAL while the other source files declared it extern. Usually one would do this by defining it (possibly with an initializer) in a source file and put the extern declaration in a header file.

static variables at global level are only visible in their own source file whether they got there via an include or were in the main file.

By the way, this is a feature of C inherited by C++. It is not specific to C++.

Justsalt
+1  A: 

The static declaration at this level of code means that the variabel is only visible in the current compilation unit. This means that only code within that module will see that variable.

if you have a header file that declares a variable static and that header is included in multiple C/CPP files, then that variable will be "local" to those modules. There will be N copies of that variable for the N places that header is included. They are not related to each other at all. Any code within any of those source files will only reference the variable that is declared within that module.

In this particular case, the 'static' keyword doesn't seem to be providing any benefit. I might be missing something, but it seems to not matter -- I've never seen anything done like this before.

As for inlining, in this case the variable is likely inlined, but that's only because it's declared const. The compiler might be more likely to inline module static variables, but that's dependent on the situation and the code being compiled. There is no guarantee that the compiler will inline 'statics'.

Mark
The benefit of 'static' here is that otherwise you're declaring multiple globals all with the same name, one for each module that includes the header. If the linker doesn't complain that's only because it's biting it's tongue and being polite.
+1  A: 

Assuming that these declarations are at global scope (i.e. aren't member variables), then:

static means 'internal linkage'. In this case, since it is declared const this can be optimised/inlined by the compiler. If you omit the const then the compiler must allocate storage in each compilation unit.

By omitting static the linkage is extern by default. Again, you've been saved by the constness - the compiler can optimise/inline usage. If you drop the const then you will get a multiply defined symbols error at link time.

Seb Rose
I believe the compiler must allocate space for a const int in all cases, since another module could always say "extern const int whatever; something("
+3  A: 

The static will mean you get one copy per file, but unlike others have said it's perfectly legal to do so. You can easily test this with a small code sample:

test.h:

static int TEST = 0;
void test();

test1.cpp:

#include <iostream>
#include "test.h"

int main(void) {
    std::cout << &TEST << std::endl;
    test();
}

test2.cpp:

#include <iostream>
#include "test.h"

void test() {
    std::cout << &TEST << std::endl;
}

Running this gives you this output:

0x446020
0x446040

slicedlime
+1  A: 

The C book (free online) has a chapter about linkage, which explains the meaning of 'static' in more detail (although the correct answer is already given in other comments): http://publications.gbdirect.co.uk/c_book/chapter4/linkage.html

Jan de Vos
+9  A: 

The static and extern tags on file-scoped variables determine whether they are accessible in other translation units (i.e. other .c or .cpp files).

  • static gives the variable internal linkage, hiding it from other translation units. However, variables with internal linkage can be defined in multiple translation units.

  • extern gives the variable external linkage, making it visible to other translation units. Typically this means that the variable must only be defined in one translation unit.

The default (when you don't specify static or extern) is one of those areas in which C and C++ differ.

  • In C, file-scoped variables are extern (external linkage) by default. If you're using C, VAL is static and ANOTHER_VAL is extern.

  • In C++, file-scoped variables are static (internal linkage) by default if they are const, and extern by default if they are not. If you're using C++, both VAL and ANOTHER_VAL are static.

From a draft of the C specification:

6.2.2 Linkages of identifiers ... -5- If the declaration of an identifier for a function has no storage-class specifier, its linkage is determined exactly as if it were declared with the storage-class specifier extern. If the declaration of an identifier for an object has file scope and no storage-class specifier, its linkage is external.

From a draft of the C++ specification:

7.1.1 - Storage class specifiers [dcl.stc] ... -6- A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal linkage because of a previous declaration and provided it is not declared const. Objects declared const and not explicitly declared extern have internal linkage.

bk1e
A: 

To answer the question, "does the static mean only one copy of VAL is created, in case the header is included by more than one source file?"...

NO. VAL will always be defined separately in every file that includes the header.

The standards for C and C++ do cause a difference in this case.

In C, file-scoped variables are extern by default. If you're using C, VAL is static and ANOTHER_VAL is extern.

Note that Modern linkers may complain about ANOTHER_VAL if the header is included in different files (same global name defined twice), and would definitely complain if ANOTHER_VAL was initialised to a different value in another file

In C++, file-scoped variables are static by default if they are const, and extern by default if they are not. If you're using C++, both VAL and ANOTHER_VAL are static.

You also need to take account of the fact that both variables are designated const. Ideally the compiler would always choose to inline these variables and not include any storage for them. There is a whole host of reasons why storage can be allocated. Ones I can think of...

  • debug options
  • address taken in the file
  • compiler always allocates storage (complex const types can't easily be inlined, so becomes a special case for basic types)
itj
A: 

const variables in C++ have internal linkage. So, using static has no effect.

a.h

const int i = 10;

one.cpp

#include "a.h"

func()
{
   cout << i;
}

two.cpp

#include "a.h"

func1()
{
   cout << i;
}

If this were a C program, you would get 'multiple definition' error for i (due to external linkage).

Nitin