編譯C++ 程式的過程
編譯C++ program的時候, 需要work with 4 kinds of file.
(1) regular source code files: 含有function definitions等, 字尾是.cpp
(2)header files: 含有function declarations(又稱function prototypes), 以及許多不同的preprocessor statements. 這些預編譯器指導語句 used to allow source code files to access externally-defined functions. Header files end in ".h
"
(一般而言是這樣的, 不過不同系統可能字尾名不同)by convention.
(3)object files: 目標檔案是Compiler 輸出的。 consist of function definitions in binary form, but they are not executable by themselves。 Object files end in ".o
"
by convention(一般而言是這樣的, 不過不同系統可能字尾名不同)by convention.)
(4) binary executables:這是我們的program linker 輸出的檔案。 The linker links together a number of object files to produce a binary file which can be directly executed. Binary executables have no special suffix on Unix
operating systems, although they generally end in ".exe
" on Windows.
The preprocessor
Before the C compiler starts compiling a source code file, the file is processed by a preprocessor. This is in reality a separate program (normally called "cpp
", for "C preprocessor"), but
it is invoked automatically by the compiler before compilation proper begins. What the preprocessor does is convert the source code file you write into another source code file (you can think of it as a "modified" or "expanded" source code file). That modified
file may exist as a real file in the file system, or it may only be stored in memory for a short time before being sent to the compiler. Either way, you don't have to worry about it, but you do have to know what the preprocessor commands do.
Preprocessor commands start with the pound sign ("#
"). There are several preprocessor commands; two of the most important are:
-
#define
. This is mainly used to define constants. For instance,#define BIGNUM 1000000
specifies that wherever the character string
BIGNUM
is found in the rest of the program,1000000
should be substituted for it. For instance, the statement:int a = BIGNUM;
becomes
int a = 1000000;
#define
is used in this way so as to avoid having to explicitly write out some constant value in many different places in a source code file. This is important in case you need to change the constant value later on; it's much less bug-prone to change it once, in the#define
, than to have to change it in multiple places scattered all over the code. -
#include
. This is used to access function definitions defined outside of a source code file. For instance:#include <stdio.h>
causes the preprocessor to paste the contents of
<stdio.h>
into the source code file at the location of the#include
statement before it gets compiled.#include
is almost always used to include header files, which are files which mainly contain function declarations and#define
statements. In this case, we use#include
in order to be able to use functions such asprintf
andscanf
, whose declarations are located in the filestdio.h
. C compilers do not allow you to use a function unless it has previously been declared or defined in that file;#include
statements are thus the way to re-use previously-written code in your C programs.
There are a number of other preprocessor commands as well, but we will deal with them as we need them.
Making the object file: the compiler
After the C preprocessor has included all the header files and expanded out all the #define
and #include
statements (as well as any other preprocessor commands that may be in the original
file), the compiler can compile the program. It does this by turning the C source code into an object code file, which is a file ending in ".o
" which contains the binary version of the source code. Object code is not directly
executable, though. In order to make an executable, you also have to add code for all of the library functions that were #include
d into the file (this is not the same as including the declarations, which is what #include
does). This
is the job of the linker (see the next section).
In general, the compiler is invoked as follows:
% gcc -c foo.c
where %
is the unix prompt. This tells the compiler to run the preprocessor on the file foo.c
and then compile it into the object code file foo.o
. The -c
option
means to compile the source code file into an object file but not to invoke the linker. If your entire program is in one source code file, you can instead do this:
% gcc foo.c -o foo
This tells the compiler to run the preprocessor on foo.c
, compile it and then link it to create an executable called foo
. The -o
option states that the next word on the line
is the name of the binary executable file (program). If you don't specify the -o
, i.e. if you just type gcc foo.c
, the executable will be named a.out
for silly historical reasons.
Note also that the name of the compiler we are using is gcc
, which stands for "GNU C compiler" or "GNU compiler collection" depending on who you listen to. Other C compilers exist; many of them have
the name cc
, for "C compiler". On Linux systems cc
is an alias for gcc
.
Putting it all together: the linker
The job of the linker is to link together a bunch of object files (.o
files) into a binary executable. This includes both the object files that the compiler created from your source code files as well
as object files that have been pre-compiled for you and collected into library files. These files have names which end in .a
or .so
, and you normally don't need to know about them, as the linker knows where most of
them are located and will link them in automatically as needed.
Like the preprocessor, the linker is a separate program called ld
. Also like the preprocessor, the linker is invoked automatically for you when you use the compiler. The normal way of using the linker
is as follows:
% gcc foo.o bar.o baz.o -o myprog
This line tells the compiler to link together three object files (foo.o
, bar.o
, and baz.o
) into a binary executable file named myprog
. Now you have a file called myprog
that
you can run and which will hopefully do something cool and/or useful.
This is all you need to know to begin compiling your own C programs. Generally, we also recommend that you use the -Wall
command-line option:
% gcc -Wall -c foo.cc
The -Wall
option causes the compiler to warn you about legal but dubious code constructs, and will help you catch a lot of bugs very early. If you want to be even more anal (and who doesn't?), do this:
% gcc -Wall -Wstrict-prototypes -ansi -pedantic -c foo.cc
The -Wstrict-prototypes
option means that the compiler will warn you if you haven't written correct prototypes for all your functions. The -ansi
and -pedantic
options cause
the compiler to warn about any non-portable construct (e.g. constructs that may be legal in gcc
but not in all standard C compilers; such features should usually be avoided).
相關文章
- C++ 編譯過程C++編譯
- 優化C++程式碼(2):C++程式碼的編譯過程優化C++編譯
- C/C++編譯過程詳解C++編譯
- .NET 程式碼編譯過程編譯
- 編譯器的編譯基本過程編譯
- 編譯過程編譯
- C程式編譯過程淺析C程式編譯
- Javac編譯過程Java編譯
- 編譯核心過程編譯
- 詳解Linux 程式編譯過程Linux編譯
- 編譯器的工作過程編譯
- EVC編譯TCPMP的過程編譯TCP
- 痛苦的過程,編譯glomap編譯
- C/C++預處理、編譯、連結過程【Z】C++編譯
- 圖解Java程式編譯解釋過程圖解Java編譯
- 編譯連結過程編譯
- 編譯過程簡介編譯
- Linux 程式編譯過程的來龍去脈Linux編譯
- JavaScript的預編譯過程分析JavaScript編譯
- Java程式碼編譯和執行的整個過程Java編譯
- ios底層 編譯過程iOS編譯
- glade 編譯過程 (轉)編譯
- vlc-android 的編譯過程Android編譯
- 編譯器的工作過程和原理編譯
- GCC編譯過程(預處理->編譯->彙編->連結)GC編譯
- iOS學習之深入理解程式編譯過程iOS編譯
- 2.深入一點理解C源程式的編譯過程編譯
- GCC編譯和連結過程GC編譯
- go語言編譯過程概述Go編譯
- 預編譯過程(AO+GO)編譯Go
- Android 專案編譯過程Android編譯
- Android Makefile 編譯過程分析Android編譯
- Hive SQL 編譯過程詳解HiveSQL編譯
- C語言編譯全過程C語言編譯
- 儲存過程編譯時卡死儲存過程編譯
- iOS編譯過程的原理和應用iOS編譯
- 初探 Go 的編譯命令執行過程Go編譯
- ASPNet_Compiler的編譯過程Compile編譯