使用extern关键字和多个翻译单元

Question

I am reading Item 4 of Scott Meyer's Effective C++ where he is trying to show an example where a static non-local object is used across different translation units. He is highlighting the problem whereby the object used in one translation unit does not know if it has been initialised in the other one prior to usage. Its page 30 in the third edition in case anyone has a copy.

The example is such:

One file represents a library:

class FileSystem{
    public:
        std::size_t numDisks() const;
    ....
};

extern FileSystem tfs;

and in a client file:

class Directory {
    public:
        Directory(some_params);
    ....
};

Directory::Directory(some_params)
{
    ...
    std::size_t disks = tfs.numDisks();
    ...
}

My two questions are thus:

1) If the client code needs to use tfs , then there will be some sort of include statement. Therefore surely this code is all in one translation unit? I do not see how you could refer to code which is in a different translation unit? Surely a program is always one translation unit?

2) If the client code included FileSystem.h would the line extern FileSystem tfs; be sufficient for the client code to call tfs (I appreciate there could be a run-time issue with initialisation, I am just talking about compile-time scope)?

EDIT to Q1

The book says these two pieces of code are in separate translation units. How could the client code use the variable tfs , knowing they're in separate translation units??

Answer 1

Here's a simplified example of how initialization across multiple TUs can be problematic.

gadget.h:

struct Foo;

extern Foo gadget;

gadget.cpp:

#include <foo.h>
#include <gadget.h>

Foo gadget(true, Blue, 'x');    // initialized here

client.cpp:

#include <foo.h>
#include <gadget.h>

int do_something()
{
    int x = gadget.frumple();   // problem!

    return bar(x * 2);
}

The problem is that it is not guaranteed that the gadget object will have been initialized by the time that do_something() refers to it. It is only guaranteed that initializers within one TU are completed before a function in that TU is called.

(The solution is to replace extern Foo gadget; with Foo & gadget(); , implement that in gadget.cpp as { static Foo impl; return impl; } and use gadget().frumple() .)

Answer 2

1) If the client code needs to use tfs, then there will be some sort of include statement. Therefore surely this code is all in one translation unit? I do not see how you could refer to code which is in a different translation unit? Surely a program is always one translation unit?

A translation unit is (roughly) a single .cpp file after preprocessing. After you compile a single translation unit you get a module object (which typically have extension .o or .obj ); after all TUs have been compiled, they are linked together by the linker to form the final executable. This is often hid by IDEs (and even by the compilers accepting multiple input files on the command line), but it's crucial to understand that building a C++ program is made in (at least) three passes: precompilation, compilation and linking.

The #include statement will include the declaration of the class and the extern declaration, telling to the current translation unit that the class FileSystem is made that way and that, in some translation unit, there's a variable tfs of type FileSystem .

2) If the client code included FileSystem.h would the line extern FileSystem tfs; be sufficient for the client code to call tfs

Yes, the extern declaration tells the compiler that in some TU there's a variable defined like that; the compiler puts a placeholder for it in the object module and the linker, when tying together the various object modules, will fix it with the address of the actual tfs variable ( defined in some other translation unit).

Keep in mind that when you write extern you are only declaring a variable (ie you are telling the compiler "trust me, there's this thing somewhere"), when you omit it you are both declaring it and defining it ("there's this thing and you have to create it here").

The distinction maybe is clearer with functions: when you write a prototype you are declaring a function ("somewhere there's a function x that takes such parameters and returns this type"), when you actually write the function (with the function body) you are defining it ("this is what this function actually does"), and, if you haven't declared it before, it counts also as a declaration.

---

For how multiple TUs are actually used/managed, you can have a look at this answer of mine .

Answer 3

Here's the example from the Standard C++03 (I've added the ah and bh headers):

[basic.start.init]/3

// a.h
struct A { A(); Use(){} };

// b.h
struct B { Use(){} };

// – File 1 –
#include "a.h"
#include "b.h"
B b;
A::A(){
    b.Use();
}

// – File 2 –
#include "a.h"
A a;

// – File 3 –
#include "a.h"
#include "b.h"
extern A a;
extern B b;
int main() {
    a.Use();
    b.Use();
}

It is implementation-defined whether either a or b is initialized before main is entered or whether the initializations are delayed until a is first used in main. In particular, if a is initialized before main is entered, it is not guaranteed that b will be initialized before it is used by the initialization of a, that is, before A::A is called. If, however, a is initialized at some point after the first statement of main, b will be initialized prior to its use in A::A.