C ++转换单元

Question

I didn't really understand what a translation unit is and how to use unnamed namespaces:

If I have a .cpp file:

namespace
{
    void extFunction()
    {
        std::cout << "Called Unnamed Namespace's function.\n";
    }
}

and a main .cpp file:

#include <iostream>
#include "ext.cpp"

using namespace std;

int main()
{
    extFunction();


    return 0;
}

Why can I access a member of an Unnamed Namespace from another file?

EDIT:

Thanks for the replies; but then, how can I use Unnamed Namespaces, and for what purpose?

Answer 1

A translation unit is basically the chunk of code that you give to a compiler to process. The compiler processes it and produces object code for the linker. The linker combines the object code from all of your translation units to form the executable. (Sometimes you'll see details that vary from this, such as not seeing a file for the object code when you have only one translation unit. The concept is still valid even though implementation details may vary.)

So typically, there is a one-to-one correspondence between .o (or .obj ) files produced when compiling and translation units. Also typically, you get one .o file for each .cpp file. Hence, it's typically reasonable to consider each .cpp file to be its own translation unit. Until you do something unconventional.

When you use an #include directive, you tell the compiler to replace that one line with the entire contents of the included file. That is, the chunk of code given to the compiler includes the code from both the original file and the included file. If you include one .cpp file into another, the chunk of code given to the compiler will include the code from two .cpp files, breaking the equivalence between .cpp files and translation units. This is generally considered a Bad idea.

---

Let's look at an example. Suppose you had a file named ext.cpp that contained the following:

namespace
{
    void extFunction()
    {
        std::cout << "Called Unnamed Namespace's function.\n";
    }
}

Also suppose you had a file named main.cpp that contained the following:

#include <iostream>
#include "ext.cpp"


int main()
{
    extFunction();
    return 0;
}

If you were to compile main.cpp , one of the first things the compiler would do is preprocess main.cpp . This modifies the file's contents, changing what the compiler sees. After preprocessing, the chunk of code that the compiler will process would look like the following.

[lots of code from the library header named "iostream"]
namespace
{
    void extFunction()
    {
        std::cout << "Called Unnamed Namespace's function.\n";
    }
}


int main()
{
    extFunction();
    return 0;
}

At this point, there is no problem calling extFunction since the compiler sees the unnamed namespace in the chunk of code it is processing.

---

Another example for the requested information about using unnamed namespaces. Similar to the above, but different. Suppose you had a file named ext.cpp that contained the following:

#include <iostream>
namespace
{
    void extFunction()
    {
        std::cout << "Called Unnamed Namespace's function in EXT.\n";
    }
}

void extPublic()
{
    extFunction();
}

Let's also provide a header ( ext.h ) that will declare the function that has external linkage.

void extPublic();

Now move on to main.cpp :

#include <iostream>
#include "ext.h"  // <-- Including the header, not the source.

namespace
{
    void extFunction()
    {
        std::cout << "Called Unnamed Namespace's function in MAIN.\n";
    }
}
int main()
{
    extFunction();
    extPublic();
    return 0;
}

Look at that! There are two definitions for the function named extFunction ! Won't the linker get confused? Not at all. Those functions are not seen outside their translation units, so there is no conflict. If you compile main.cpp , compile ext.cpp , and link main.o and ext.o into a single executable, you get the following output.

Called Unnamed Namespace's function in MAIN.
Called Unnamed Namespace's function in EXT.

One benefit of an unnamed namespace is that you don't have to worry about conflicting with names in another source file's unnamed namespace. (This becomes a much bigger benefit when your project grows to encompass hundreds of source files.)