To get a deeper understanding of C + +, you need to know what a program has done from start to finish, and how it did it.
So I compiled from C + + to execute the process, to resolve the program is how to run.
First, let's start by talking about the previous C + + compilation process. The C + + compilation process contains a precompiled-"compilation-compile-" link. Referred to as a running file. (The. exe file under the Windows platform).
Precompilation mainly expands the operations including header files, macro definitions, and so on. For example, a simple main program, compiled pre-compiled, the file comparison.
Watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqv/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity /center ">
Watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqv/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity /center "> can see the inside of the macro has been removed.
Set the macro to False. Then the contents of the macro will also be displayed. Header files too. Assuming you include a. h file, the entire. h file is included.
The assembly process is the process of compiling precompiled files into assembly code. The whole process will include syntax, lexical analysis, and some optimization operations.
The compilation process is actually the assembly that can synthesize a phase into the target code. That is, the binary file.
Linking is the process of linking a single compiled file to a running program. The Pre-compilation, compilation, and compilation are all positive for a single file, one for the compilation unit, and the other for the compiled unit file and the application to the library file to which the link will be all associated. Once the link is processed, the previously compiled file is assumed to be useful to functions defined in other files. Global variables. In this process, it will be parsed.
First look at what the compiled file looks like (the compiled obj file has been VS2012 as an example. Different compiler styles may be different.
)
Pre-compilation files
#include "Car.h"
int main (int argc, char* argv[])
{
car* p = new Car ();
Delete p;
return 1;
}
The post-compilation look (because the compiled file information is too much to post only the unresolved symbols in the inside part.)
)
UNDEF:00002DC4; int __thiscall Car::car (Car *__hidden this)
UNDEF:00002DC4 extrn?
?
[email protected]@[email protected]: near; CODE XREF: _main+63p
UNDEF:00002DC8; int __thiscall Car::~car (Car *__hidden this)
Undef:00002dc8 extrn??
[email protected]@[email protected]: Near
UNDEF:00002DC8; CODE xref:car:: ' scalar deleting destructor ' (UINT) +26p
UNDEF:00002DCC; __fastcall _rtc_checkstackvars (x, X)
UNDEF:00002DCC extrn @[email Protected]:near
UNDEF:00002DCC; CODE XREF:STD::_STRING_ALLOC<0,STD::_STRING_BASE_TYPES<CHAR,STD::ALLOCATOR<CHAR>>>::_ALLOC_ Proxy (void) +68p
UNDEF:00002DCC; $LN 19+72p ...
undef:00002dd0; __fastcall __security_check_cookie (x)
Undef:00002dd0 extrn @[email Protected]:near
undef:00002dd0; CODE XREF:[email protected]@[email protected]@[email protected]@[email protected]+fp
undef:00002dd0; __ehhandler$??
[email protected] [Email protected] @@ [emailprotected]@[email protected][email protected] @@@ [Email protected] @[email protected]@[email protected]@z+fp ...
UNDEF:00002DD4; __stdcall _cxxthrowexception (x, X)
The implemented function becomes a bunch of assembly instructions when compiled files are used (viewed in Disassembly assembly code). The functions that are referenced in other files will become a characteristic symbol (such as the constructor for calling the car class above extrn[email protected]@[email protected]: Near) These symbols are called as parsed symbols. Indicates that the link needs to be parsed.
The generated name of the symbol is detailed in relation to the compiler, but it is guaranteed that a function name of a class must be unique within the same compilation, since we have included Car.h in the precompiled phase so the compiler can correctly generate the name of the function. Then, in the link will find the name of the function of the word name, replace this identity with the address of the function. This enables the link to be implemented.
In the symbol resolution phase, the linker scans the entire target file and library files from left to right in the order in which they are now in the command line. During this time it maintains several collections: (1) Set E is a collection of all target files that will be merged together to form a running file. (2) the set U is a set of unresolved symbols (unresolved symbols, for example, symbols that have been referenced but not yet defined). (3) Set D is a collection of symbols that have been previously added to the target file definition of E. At the beginning, E, U, D are empty.
(1): For each input file f in the command line, the linker determines whether it is a target file or a library file, assuming it is the destination file. The f is added to E, and the unresolved symbols and defined symbols in F are added to the set of U and D respectively. The next input file is then processed.
(2): Assuming that f is a library file, the linker will attempt to match all the unresolved symbols in U with the symbols defined by each target module in F. Assuming that a target module m defines an unresolved symbol in U, the M is added to E and the unresolved symbols and defined symbols in M are added to the U and D sets, respectively. The process continues over and over for all target modules in F until it reaches a fixed point, where U and D no longer change. The target module, which is not added to E in F, is simply discarded and the linker continues to process the next input file.
(3): Assume that an existing symbol is added to D during processing, or U is not empty when scanning the total input file. The linker errors and stops the action. Otherwise, it merges all of the target files in E to generate a running file.
C + + compilation, the execution process specific explanation.