Translation Unit

Hello, All:

What is C++ translation unit? Is it talking about file *.h/*.cpp? Why is that?

Thanks.

csheng

I'm sure a google search or glance through the standard will provide a well-worded definition - but the big picture is all of the code seen by the compiler and compiled into an object file.

so if you've got:

main.c

#include<iostream>
#include<cstdlib>

int main(void) {return 0;}

EOF

then the translation unit is the contents of iostream.h plus the contents of all of the files it includes (and so on recursivly)

dido on cstdlib

and finally the function main.

For most (command line) compilers if you give it multiple .c files they are combined into a single translation unit.

A translation unit is usually a *.c or *.cpp file.

Most compilers do NOT compile multiple *.c/*.cpp fies into a single translation unit. They remain seperate (even with command line compilers).
FYI: Most compilers are command line compilers.

A *.c file can be combine into another *.c file as a single translation unit IF, the second *.c file includes the other.

#include <foo.c>

Otherwise for the most part each *.c file is a single translation unit.

Quote:

---

Originally posted by Axter
Most compilers do NOT compile multiple *.c/*.cpp fies into a single translation unit. They remain seperate (even with command line compilers).

---

Out of curiosity; is this dictated by the standard or simply compiler convention. I know the standard does provide a definition of translation unit but its not the easist doc to find stuff in quickly.

It appears to be clear that .c file is compiled to a translation, but if the a.c file has

#include "a.h"

Compiler will compile these two file to a translation unit.

However, a a.h file can be compiled to a single translation unit as well.

In this case, what is the use of the translation unit? is it being used to determine variable/object scope?

I was initially curious to know how translation unit is generated, and more importantly, how it is used?

Regards,
csheng

Quote:

---

Originally posted by csheng
However, a a.h file can be compiled to a single translation unit as well.

---

You have a compiler that compiles .h files?

well since we are in the VC++ forum, I'll just add there is documentation in msdn look for 'translation phazes" "translation units"

Let me re-phrase the question.

If a.h file is included in both a.c and b.c file, both c file are to be compiled into two translation units.

In this case, what is the use of the translation unit? is it being used to determine variable/object scope?

I was initially curious to know how translation unit is generated, and more importantly, how it is used?

Maybe it is a stupid question, who cares?

csheng

:confused:

Thanks to mclark for pointing to searching msdn. It did expalin something about translation phase.

But I still could not find what role translation unit is playing in MSDN. This is a C question, but it is also a c++ question as well.



csheng
:o

Ooops, I found it in MSDN, thanks very much.

Here is from MSDN for those of you who do not want to search MSDN. (Actually I use MSDN very often).

C and C++ programs consist of one or more source files, each of which contains some of the text of the program. A source file, together with its include files (files that are included using the #include preprocessor directive) but not including sections of code removed by conditional-compilation directives such as #if, is called a "translation unit."

Source files can be translated at different times — in fact, it is common to translate only out-of-date files. The translated translation units can be kept either in separate object files or in object-code libraries. These separate translation units are then linked to form an executable program or a dynamic-link library (DLL).

Translation units can communicate using:

Calls to functions that have external linkage.
Calls to class member functions that have external linkage.
Direct modification of objects that have external linkage.
Direct modification of files.
Interprocess communication (for Microsoft® Windows®-based applications only).


Thanks to mclark again.

csheng

:)

Quote:

---

Thanks to mclark again.

---

Actually, it would appear that Mick was the first to suggest searching MSDN...

Though I would almost expect that one would hit MSDN before CG... (but from experience I am quite aware that that is not the case).