目录
1. 程序的翻译环境和执行环境
2. 翻译环境
可执行程序形成的流程图:
2.1预处理(预编译)
命令如下:
2.2 编译
编译过程的命令如下:
2.2.1 词法分析
2.2.2 语法分析
2.2.3 语义分析
2.3 汇编
汇编的命令如下:
2.4 链接
比如:
3.运行环境
4.预处理详解
4.1 预定义符号
例子:
4.2 #define
4.2.1 #define 定义标识符
例子:
4.2.2 #define 定义宏
4.2.3 #define(宏) 替换规则
4.2.4 带副作用的宏参数
4.2.5 宏和函数对比
宏和函数的一个对比
命名约定
4.2.6 #和##运算符
#运算符
##运算符
比如:
4.3 命名约定
4.4 #undef
4.5 命令行定义
编译指令:
4.6 条件编译
4.7 文件包含
4.7.1 头文件被包含的方式:
Linux环境的标准头文件的路径:
VS环境的标准头文件的路径:
4.7.2 嵌套文件包含
4.8 其他预处理指令
1. 程序的翻译环境和执行环境
在ANSI C的任何一种实现中,存在两个不同的环境
第1种是翻译环境,在这个环境中源代码被转换为可执行的机器指令
第2种是执行环境,它用于实际执行代码
2. 翻译环境
那翻译环境是怎么将源代码转换为可执行的机器指令的呢?这里我们就得展开开讲解一下翻译环境所做的事情,其实翻译环境是由编译和链接两个大的过程组成的,而编译又可以分解成:预处理(有些书也叫预编译)、编译汇编三个过程。
一个C语言的项目中可能有多个.c文件一起构建,那多个.c 文件如何生成可执行程序呢?
多个.c文件单独经过编译器,编译处理生成对应的目标文件。
注:在Windows环境下的目标文件的后缀是.obj,Linux环境下目标文件的后缀是.0多个目标文件和链接库一起经过链接器处理生成最终的可执行程序。
链接库是指运行时库(它是支持程序运行的基本函数集合)或者第三方库。
可执行程序形成的流程图:
2.1预处理(预编译)
在预处理阶段,源文件和头文件会被处理成为.i为后缀的文件。
在 gcc环境下想观察一下,对 test.c 文件预处理后的.i文件
命令如下:
gcc -E test.c -o test.i
预处理阶段主要处理那些源文件中#开始的预编译指令。比如:#include,#define,处理的规则如下:
将所有的 #define 删除,并展开所有的宏定义。
处理所有的条件编译指令,如:#if、#ifdef、#elif、#else、#endif。
处理#include 预编译指令,将包含的头文件的内容插入到该预编译指令的位置。这个过程是递归进行的,也就是说被包含的头文件也可能包含其他文件。
删除所有的注释
添加行号和文件名标识,方便后续编译器生成调试信息等
保留所有的#pragma的编译器指令,编译器后续会使用。经过预处理后的.i 文件中不再包含宏定义,因为宏已经被展开。并且包含的头文件都被插入到.i文件中。所以当我们无法知道宏定义或者头文件是否包含正确的时候,可以查看预处理后的.i 文件来确认。
2.2 编译
编译过程就是将预处理后的文件进行一系列的:词法分析、语法分析、语义分析及优化,生成相应的汇编代码文件。
编译过程的命令如下:
gcc -S test.i -o test.s
对下面代码进行编译的时候,会怎么做呢?假设有下面的代码
array[index] = (index+4)*(2+6);
2.2.1 词法分析
将源代码程序被输入扫描器,扫描器的任务就是简单的进行词法分析,把代码中的字符分割成一系列的记号(关键字、标识符、字面量、特殊字符等)
上面程序进行词法分析后得到了16个记号:
2.2.2 语法分析
接下来语法分析器,将对扫描产生的记号进行语法分析,从而产生语法树。这些语法树是以表达式为节点的树
2.2.3 语义分析
由语义分析器来完成语义分析,即对表达式的语法层面分析。编译器所能做的分析是语义的静态分析。静态语义分析通常包括声明和类型的匹配,类型的转换等。这个阶段会报告错误的语法信息
2.3 汇编
汇编器是将汇编代码转转变成机器可执行的指令(二进制指令),每一个汇编语句几乎都对应一条机器指令。就是根据汇编指令和机器指令的对照表一一的进行翻译,也不做指令优化
汇编的命令如下:
gcc -c test.s -o test.o
2.4 链接
链接是一个复杂的过程,链接的时候需要把一堆文件链接在一起才生成可执行程序。
链接过程主要包括:地址和空间分配,符号决议和重定位等这些步骤
链接解决的是一个项目中多文件、多模块之间互相调用的问题
比如:
在一个C的项目中有2个.c文件(test.c和add.c),代码如下
我们已经知道,每个源文件都是单独经过编译器处理生成对应的目标文件。
test.c 经过编译器处理生成 test.o
add.c经过编译器处理生成 add.o
我们在 test.c的文件中使用了 add.c 文件中的 Add 函数和 g val 变量。
我们在 test.c文件中每一次使用 Add 函数和 g_va1 的时候必须确切的知道 Add 和 g_va1 的地址,但是由于每个文件是单独编译的,在编译器编译 test.c的时候并不知道 Add 函数和 g_va1 变量的地址,所以暂时把调用Add 的指令的目标地址和 g_va1 的地址搁置。等待最后链接的时候由链接器根据引用的符号 Add 在其他模块中查找 Add 函数的地址,然后将 test.c中所有引用到 Add 的指令重新修正,让他们的目标地址为真正的 Add 函数的地址,对于全局变量g_va1 也是类似的方法来修正地址。这个地址修正的过程也被叫做:重定位。
3.运行环境
1.程序必须载入内存中。在有操作系统的环境中:一般这个由操作系统完成。在独立的环境中,程序的载入必须由手工安排,也可能是通过可执行代码置入只读内存来完成。
2.程序的执行便开始。接着便调用main函数
3.开始执行程序代码。这个时候程序将使用一个运行时堆栈(stack),存储函数的局部变量和返回地址。程序同时也可以使用静态(static)内存,存储于静态内存中的变量在程序的整个执行过程一直保留他们的值
4.终止程序。正常终止main函数;也有可能是意外终止
4.预处理详解
4.1 预定义符号
__FILE__ //进⾏编译的源⽂件
__LINE__ //⽂件当前的⾏号
__DATE__ //⽂件被编译的⽇期
__TIME__ //⽂件被编译的时间
__STDC__ //如果编译器遵循ANSI C,其值为1,否则未定义
这些预定义符号都是语言内置的。
例子:
printf("file:%s line:%d\\n", __FILE__, __LINE__);
4.2 #define
4.2.1 #define 定义标识符
#define name stuff
例子:
#define MAX 1000
#define reg register //为 register这个关键字,创建⼀个简短的名字
#define do_forever for(;;) //⽤更形象的符号来替换⼀种实现
#define CASE break;case //在写case语句的时候⾃动把 break写上。
// 如果定义的 stuff过⻓,可以分成⼏⾏写,除了最后⼀⾏外,每⾏的后⾯都加⼀个反斜杠(续⾏符)。
#define DEBUG_PRINT printf("file:%s\\tline:%d\\t \\
date:%s\\ttime:%s\\n" ,\\
__FILE__,__LINE__ , \\
__DATE__,__TIME__ )
'\\'是续行符
提问:在define定义标识符的时候,要不要在最后加上 ‘;’ ?
比如:
#define MAX 1000;
#define MAX 1000
加上';'就变成了"MAX = 1000;" 所以建议不要加上 ';' ,这样容易导致问题。
比如下面的场景:
if(condition)
max = MAX;
else
max = 0;
这里会出现语法错误
4.2.2 #define 定义宏
#define 机制包括了一个规定,允许把参数替换到文本中,这种实现通常称为宏(macro)或定义宏(define macro)
下面是宏的申明方式:#define name( parament-list ) stuff其中的 parament-list 是一个由逗号隔开的符号表,它们可能出现在stuff中
#define name( parament-list ) stuff
注意:参数列表的左括号必须与name紧邻。如果两者之间有任何空白存在,参数列表就会被解释为stuff的一部分。
如:
#define SQUARE( x ) x * x
这个宏接收一个参数 x .如果在上述声明之后,你把
置于程序中,预处理器就会用下面这个表达式替换上面的表达式:
警告:这个宏存在一个问题:观察下面的代码段:
乍一看,你可能觉得这段代码将打印36这个值。事实上,它将打印11
为什么?
替换文本时,参数x被替换成a + 1,所以这条语句实际上变成了:printf ("%d\\n",a + 1 * a + 1 );
这样就比较清晰了,由替换产生的表达式并没有按照预想的次序进行求值
在宏定义上加上两个括号,这个问题便轻松的解决了:
这样预处理之后就产生了预期的效果:
这里还有一个宏定义:
定义中我们使用了括号,想避免之前的问题,但是这个宏可能会出现新的错误
这将打印什么值呢?
warning:
看上去,好像打印100,但事实上打印的是55.我们发现替换之后:
乘法运算先于宏定义的加法,所以出现了 55
这个问题,的解决办法是在宏定义表达式两边加上一对括号就可以了
提示:所以用于对数值表达式进行求值的宏定义都应该用这种方式加上括号,避免在使用宏时由于参数中的操作符或邻近操作符之间不可预料的相互作用
4.2.3 #define(宏) 替换规则
在程序中扩展#define定义符号和宏时,需要涉及几个步骤。
1. 在调用宏时,首先对参数进行检查,看看是否包含任何由#define定义的符号。如果是,它们首先被替换。
2. 替换文本随后被插入到程序中原来文本的位置。对于宏,参数名被他们的值替换。
3. 最后,再次对结果文件进行扫描,看看它是否包含任何由#define定义的符号。如果是,就重复上述处理过程。
注意:
1. 宏参数和#define 定义中可以出现其他#define定义的变量。但是对于宏,不能出现递归。
2. 当预处理器搜索#define定义的符号的时候,字符串常量的内容并不被搜索
4.2.4 带副作用的宏参数
当宏参数在宏的定义中出现超过一次的时候,如果参数带有副作用,那么你在使用这个宏的时候就可能出现危险,导致不可预测的后果。副作用就是表达式求值的时候出现的永久性效果
例如:
MAX宏可以证明具有副作用的参数所引起的问题
这里我们得知道预处理器处理之后的结果是什么:
所以输出的结果是:
4.2.5 宏和函数对比
宏通常被应用于执行简单的运算。比如在两个数中找出较大的一个
那为什么不用函数来完成这个任务?
原因有二:
1. 用于调用函数和从函数返回的代码可能比实际执行这个小型计算工作所需要的时间更多。所以宏比函数在程序的规模和速度方面更胜一筹
2. 更为重要的是函数的参数必须声明为特定的类型。所以函数只能在类型合适的表达式上使用。反之这个宏怎可以适用于整形、长整型、浮点型等可以用于>来比较的类型。宏是类型无关的。
当然和宏相比函数也有劣势的地方:
1. 每次使用宏的时候,一份宏定义的代码将插入到程序中。除非宏比较短,否则可能大幅度增加程序的长度
2. 宏是没法调试的。
3. 宏由于类型无关,也就不够严谨。
4. 宏可能会带来运算符优先级的问题,导致程容易出现错。
宏有时候可以做函数做不到的事情。
比如:宏的参数可以出现类型,但是函数做不到
宏和函数的一个对比
命名约定
一般来讲函数的宏的使用语法很相似。所以语言本身没法帮我们区分二者。那我们平时的一个习惯是:把宏名全部大写函数名不要全部大写
4.2.6 #和##运算符
如何把参数插入到字符串中?
首先我们看看这样的代码:
这里输出的是不是hello bit ?
答案是确定的:是。
我们发现字符串是有自动连接的特点的
#运算符
#运算符将宏的一个参数转换为字符串字面量。它仅允许出现在带参数的宏的替换列表中。
#运算符所执行的操作可以理解为“字符串化"当我们有一个变量int a=10;的时候,我们想打印出:the value of a is 10就可以写:
当我们按照下面的方式调用的时候:
PRINT(a);//当我们把a替换到宏的体内时,就出现了#a,而#a就是转换为"a",时一个字符串代码就会被预处理为:
运行代码就能在屏幕上打印:
##运算符
##可以把位于它两边的符号合成一个符号,它允许宏定义从分离的文本片段创建标识符。 ## 被称为记号粘合这样的连接必须产生一个合法的标识符。否则其结果就是未定义的。这里我们想想,写一个函数求2个数的较大值的时候,不同的数据类型就得写不同的函数。
比如:
但是这样写起来太繁琐了,现在我们这样写代码试试:
使用宏定义不同函数
注:这样的连接必须产生一个合法的标识符。否则其结果就是未定义的
4.3 命名约定
一般来讲函数的宏的使用语法很相似。所以语言本身没法帮我们区分二者。那我们平时的一个习惯是:
把宏名全部大写
函数名不要全部大写
4.4 #undef
这条指令用于移除一个宏定义
4.5 命令行定义
许多C 的编译器提供了一种能力,允许在命令行中定义符号。用于启动编译过程。
例如:当我们根据同一个源文件要编译出不同的一个程序的不同版本的时候,这个特性有点用处。(假定某个程序中声明了一个某个长度的数组,如果机器内存有限,我们需要一个很小的数组,但是另外一个机器内存大写,我们需要一个数组能够大写。)
编译指令:
4.6 条件编译
在编译一个程序的时候我们如果要将一条语句(一组语句)编译或者放弃是很方便的。因为我们有条件编译指令
比如说:调试性的代码,删除可惜,保留又碍事,所以我们可以选择性的编译
#include <stdio.h>
#define __DEBUG__
int main()
{
int i = 0;
int arr[10] = {0};
for(i=0; i<10; i++)
{
arr[i] = i;
#ifdef __DEBUG__
printf("%d\\n", arr[i]);//为了观察数组是否赋值成功。
#endif //__DEBUG__
}
return 0;
}
常见的条件编译指令:都是以#enndif 结尾
4.7 文件包含
我们已经知道, #include 指令可以使另外一个文件被编译。就像它实际出现于 #include 指令的地方一样。
这种替换的方式很简单:
预处理器先删除这条指令,并用包含文件的内容替换。
这样一个源文件被包含10次,那就实际被编译10次。
4.7.1 头文件被包含的方式:
本地文件包含
查找策略:先在源文件所在目录下查找,如果该头文件未找到,编译器就像查找库函数头文件一样在标准位置查找头文件。如果找不到就提示编译错误。
Linux环境的标准头文件的路径:
VS环境的标准头文件的路径:
注意按照自己的安装路径去找。
库文件包含
查找头文件直接去标准路径下去查找,如果找不到就提示编译错误。
这样是不是可以说,对于库文件也可以使用 “” 的形式包含?
答案是肯定的,可以。
但是这样做查找的效率就低些,当然这样也不容易区分是库文件还是本地文件了。
4.7.2 嵌套文件包含
如果出现这样的场景:
omm.h和comm.c是公共模块。
test1.h和test1.c使用了公共模块。
test2.h和test2.c使用了公共模块。
test.h和test.c使用了test1模块和test2模块。
这样最终程序中就会出现两份comm.h的内容。这样就造成了文件内容的重复。
如何解决这个问题?
答案:条件编译。
每个头文件的开头写:
或者:
就可以避免头文件的重复引入
4.8 其他预处理指令
参考《C语言深度解剖》学习
评论前必须登录!
注册