头文件中的变量声明-是静态的还是非静态的?

在重构一些 #defines时,我遇到了类似于 C + + 头文件中的声明:

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

问题是,如果有的话,静态会有什么不同?注意,由于经典的 #ifndef HEADER #define HEADER #endif技巧(如果这很重要的话) ,不可能包含多个标头。

静态是否意味着只创建 VAL的一个副本,以防头被多个源文件包含?

103118 次浏览

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.

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.

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. In C, without the static you would need to ensure 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.


Editor's note: In C++, const objects with neither the static nor extern keywords in their declaration are implicitly static.

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

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.

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

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

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.

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)

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

You can’t declare a static variable without defining it as well (this is because the storage class modifiers static and extern are mutually exclusive). A static variable can be defined in a header file, but this would cause each source file that included the header file to have its own private copy of the variable, which is probably not what was intended.

const variables are by default static in C++, but extern C. So if you use C++ this no sense what construction to use.

(7.11.6 C++ 2003, and Apexndix C has samples)

Example in compare compile/link sources as C and C++ program:

bruziuz:~/test$ cat a.c
const int b = 22;
int main(){return 0;}
bruziuz:~/test$ cat b.c
const int b=2;
bruziuz:~/test$ gcc -x c -std=c89 a.c b.c
/tmp/ccSKKIRZ.o:(.rodata+0x0): multiple definition of `b'
/tmp/ccDSd0V3.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status
bruziuz:~/test$ gcc -x c++ -std=c++03 a.c b.c
bruziuz:~/test$
bruziuz:~/test$ gcc --version | head -n1
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609