了解C编译器的工作流程有助于C程序员解决编译代码过程中出现的问题。市面上凡是讲解得还算全面的C语言书籍中都或多或少对此有所提及。

让我们在这里来回顾一下C编译器的工作流程！一般C编译器的工作流程大致分为：预编译、编译、生成目标代码（汇编）和连接这四个主要步骤。我们用实例具体描述一下这四个步骤，以最著名的GCC编译器结合helloworld.c文件为例:

/* helloworld.c */
int main() {
    printf("hello, world\n");
    return 0;
}

使用Gcc编译该源文件，我们看到编译器有如下输出（省略了一些内容）：

$ gcc -v -o helloworld helloworld.c
… …
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'

 /usr/lib/gcc/i486-linux-gnu/4.4.3/cc1 -quiet -v helloworld.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase helloworld.c -mtune=generic -march=i486 -auxbase helloworld -version -fstack-protector -o /tmp/ccgoLMLQ.s
… …

COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'
 as -V -Qy -o /tmp/ccN9HVdH.o /tmp/ccgoLMLQ.s
… …

COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.3/collect2 –build-id –eh-frame-hdr -m elf_i386 –hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o helloworld -z relro /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../.. -L/usr/lib/i486-linux-gnu /tmp/ccN9HVdH.o -lgcc –as-needed -lgcc_s –no-as-needed -lc -lgcc –as-needed -lgcc_s –no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crtn.o

可以明显看出，Gcc的输出大致分为三段：
首先是调用/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1对源文件helloworld.c进行预编译和编译，生成汇编代码文件/tmp/ccgoLMLQ.s；
然后，汇编器as被启动，编译ccgoLMLQ.s，生成目标代码文件/tmp/ccN9HVdH.o；
最后，链接器collect2将目标文件和一些库文件连接在一起，形成可执行程序helloworld。

简单总结一下就是：
- cc1负责预编译源代码helloworld.c，生成helloworld.i(指代预编译后生成的中间文件，很多编译器为了效率并不使用临时文件，而使用管道等方法)，我们可以通过gcc -E helloworld.c > helloworld.i得到helloworld.i这个文件；
- cc1将helloworld.i作为输入，对预编译后的源文件进行编译，生成汇编代码文件helloworld.s（指代编译后的汇编代码文件）。我们可以通过gcc -S helloworld.c得到helloworld.s文件；
- as负责根据helloworld.s生成目标代码文件helloworld.o，我们可以通过gcc -c helloworld.c来获得helloworld.o；
- collect2负责将目标代码与各种库文件连接，形成最终可执行文件helloworld。

其实以上不是这次重点要谈的。粗略了解了以上流程的确有助于解决编译过程中的问题，但是还不能解决全部，你需要了解更多。关于链接过程，我在博客里曾多次谈过，这里就不说了。as执行的汇编过程基本不会出现问题，这里也不谈，我们这次重点要关注的就是C编译器在预编译和编译过程中的一些细节。

C标准(C99)在5.1.1.2小节将C编译器工作流程分成了八个标准阶段，我这里也是结合这八个阶段并按照我的理解做进一步的解释的。在开始之前我们要明确下面这八个阶段中的前七个都是针对一个编译单元/翻译单元的，自始至终你都要牢记这一点。

第一阶段：物理源文件中的多字节字符被映射到源字符集（具体以何种字符编码方式映射与编译器的实现相关）。三字符序列(或称为三字符组)被替换为相应的单字符的内部表示。

标准中的语言总是那么绕口。这里主要说的是编译器读取物理源文件的内容，此时编译器并不知道该源文件中的多字节字符采用的是何种字符集编码方式。以GCC为例，GCC默认源码文件多字节字符的编码为utf8，而GCC其作为内部表示的源字符集默认也是utf8，所以默认情况下，这个阶段GCC不会对源文件中的内容做任何转换。

例如我们有一个内码格式为GBK的名为foo.c的文件：
/* foo.c */
int main() {
    printf("中国\n");
}

按照GBK码表，其中的字符串常量"中国"的编码为d6 d0 b9 fa。将该文件传到一个locale为utf8的平台上编译，我们发现GCC并未尝试将GBK转换为其内部表示的编码格式utf8：
$ gcc -E foo.c > foo.i
$ od -x foo.i
我们可以看到foo.i中"中国"二个字的编码依旧为d6 d0 b9 fa。

不过我们可以显式告知编译器源码文件的编码格式，如果其所在OS支持从该编码格式到utf8的转换，则GCC会在第一阶段就进行这个转换：
$ gcc -E foo.c > foo.i -finput-charset='gbk'
这次foo.i中的"中国"二字的编码变成了utf编码：e4 b8 ad e5 9b bd

三字符序列(trigraphs)的替换过程也是在第一阶段进行的，也就是发生在词法分析之前以及识别字符常量和字符串常量中的转义字符之前。我们看看这个例子：
/* trigraphs_test.c */
int main(int argc, const char *argv[]) {
    printf("hello??/n");
    printf("world\n");
    return 0;
}

$ gcc -E trigraphs_test.c > trigraphs_test.i -std=c99

可以看到trigraphs_test.i内容为：
int main(int argc, const char *argv[]) {
    printf("hello\n");
    printf("world\n");
    return 0;
}

三字符序列发生在转义之前，所以printf("hello??/n");在字符串转义过程之前就先进行了三字符序列的替换(否则编译器会报错)，替换成了printf("hello\n");后续在字符串常量转义字符时\n才被当作了换行符处理。

第二阶段：这个阶段比较简单，说白了就是去掉续行符，即所有相邻的'\'和'\n'的组合，将物理源代码的行拼接为逻辑源代码行。

第三阶段：源文件被分解为预处理词法元素(tokens)和空白字符序列（包括注释）。源文件不应该以一个部分预处理词法元素或部分注释结束(例如一个注释不能一半在一个文件中，而另一半在接下来的文件中)。每条注释都被替换成一个空格字符。换行符保留。将非空空白字符序列(诸如空格、TAB键等，除了换行符）保留还是替换为一个空格字符则由编译器的实现决定

这个阶段中预处理器开始执行了词法分析，删除不必要字符，转换字符，为后续处理营造一个干净的环境。

第四阶段：预处理指示符被执行，宏调用被扩展，_Pragma一元操作符表达式被执行。对通用字符名(UCN)进行词法元素连接的行为是未定义的。预处理器从阶段1到阶段4递归地处理源文件中#include预处理指示符中的头文件或源文件。最后所有预处理指示符被删除。

这个阶段预处理器是主力，其结果是我们得到了一个包含了诸多头文件内容的预处理后的编译单元文件，用作后续处理的输入。

第五阶段：字符常量、字符串常量中的源字符集字符或转义字符序列都会被转换为相应的执行字符集中的字符；如果执行字符集中没有对应的字符（除了宽字符null），则转换成什么由编译器的实现确定。

注意与第一阶段不同的是：这个是在foo.i的基础上，也就是说在GCC默认foo.i中的字符都是utf8的基础上，将代码中的字符常量以及字符串常量中的源字符集字符（默认utf8）转换为执行字符集(默认也是utf8)，包括通用字符名(UCN)。

注意UCN也可以看成转义字符序列，在这个阶段被转换为执行字符集，如：
char *a = "\u4e2d\u56fd"; /* 两个ucn字符为'中国' */

我们通过gcc -S得到源文件对应的.s汇编文件，从汇编文件内容可以看到a的内部表示为：
.string "\344\270\255\345\233\275"
即utf编码的'中国'。

另外这里说的字符和字符串串常量，也包括宽字符和宽字符串，其转换为内部表示的过程也在这个阶段进行，例如下面代码：
wchar w[] = L"中国";

该代码进行了一次utf8到宽字符内部表示（GCC为unicode32）的转换。

第六阶段：将相邻两个字符串字面元素连接起来
这个阶段用一个例子就能说明问题，很简单：
char *a = "hello"
          " world";

经过编译后，我们可以看到.s文件中关于a的定义：
.string "hello world"

这就相当于将"hello"和" world"连接起来，形成"hello world"。

第七阶段：编译器执行词法分析、语法分析以及语义分析，生成该编译单元对应的目标代码(.o文件)。
第八阶段：Resolve所有外部符号(包括变量和函数)，并将诸多编译单元的.o以及外部库连接成可执行程序。

个人感觉编译阶段中的难点就是几个涉及字符集转换的阶段，如第一个阶段和第五个阶段，不过只要弄清楚编译器是如何做的，相信所有编译问题都可以被轻松解决了。

相信今天上午进行的2011美洲杯阿根廷队的首演又让广大阿根廷球迷"上火"了。同为阿根廷球迷，我和大家的心情是一样一样的。

事实上我也只是看了下半场比赛。这里我还是要提醒那些尚未亲眼观看阿根廷的比赛的朋友们：你需要有一颗坚强的心，否则伤不起啊。一句话概括这场比赛：后防风声鹤唳、中场平庸无奇、前场单打独斗。这似乎是这几年来阿根廷队一贯所表现出来的风格。

阿根廷球迷，真悲哀啊。我们遇到阿根廷足球一个低谷时期。阿根廷足球人才培养管理混乱，青黄不接，特别是中场人才和后卫人才严重短缺。最明显的表象就是阿根廷两大豪门的现状：河床降级，博卡挣扎。前年(2009)的南美解放者杯冠军拉普拉塔大学生队的中场核心居然还是年迈沧桑的贝隆，这与世界新王西班牙的人才辈出对比反差明显。在以上的大背景下，这场比赛的结果似乎也就不足为奇了。

肯定有人反驳：我们有两届金球先生、世界第一人梅西啊，我们应该取得胜利才对。提到梅西，更让人痛苦。可怜梅西了。生不逢时啊，赶上了这么一个阿根廷队。综合阿根廷、梅西以及本场比赛，我这里抛出几个个人观点：

(一) 梅西，仅是这支阿根廷队名义上的核心。
世界上任何一只球队如果拥有了梅西，主教练都会让梅西作为进攻核心。巴蒂斯塔也不例外。赛前巴蒂斯塔就不止一次说过：梅西是阿根廷的进攻核心，其他人都应该适应梅西的提法。但通过这场比赛来看，梅西顶多算是一个名义上的核心：首先上半场顶在中锋位置的梅西很无奈，同伴根本无法创造出射门机会。还得梅西自己回中场给特维斯和拉维奇传好球。二是下半场回撤到中场组织的梅西，拿球的机会太少。你看看巴萨的比赛，哈维和小白传球的第一选择就是梅西。而反观阿根廷，似乎大家更愿意传球给特维斯那个”人民公仆“。三是即使梅西拿到了皮球，同伴也没有及时跑出空间，梅西无法传出好球(对比巴萨比赛中哈维、伊涅斯塔的传球和梅西的跑位就再清楚不过了)，同样也没有人上来与梅西呼应，巴萨的比赛中经常会看到梅西、哈维和小白三人在对方的前场快速倒脚，这样做一是不丢球，二是让对方防线随动，露出破绽，等待杀机。

(二) 特维斯破坏阿根廷整体进攻节奏，抢了梅西的球权，与梅西在进攻区域无法共存
2006年的世界杯让我们认识了特维斯，但也是那届世界杯让我对特维斯的印象就不是很好。特维斯在前场接到球后，太喜欢个人带球或个人射门了。本来一次很好的团队配合，到他这就嘎然而止了。而且结果不是球丢了，就是射门偏出好远。在与队友主动寻求配合方面，他与梅西比起来差了好远，也许这就是踢球文化不同导致的吧。在巴萨熏陶出来的与在曼城熏陶出来的就是不一样。有了特维斯在前场，似乎梅西就很郁闷，拿球的机会也变少了，射门机会更是少了很多，因为都被特维斯射光了。今天下半场似乎特维斯拿球次数比梅西还多出很多。该是巴蒂斯塔抉择的时候了，要么拿下特维斯，让阿根廷走的更远；要么留下特维斯，早早离开美洲杯。

(三) 梅西需要改变，需要快速适应阿根廷的现状。
如果说梅西更适合西班牙队，相信了解梅西的人都会点头同意。没错，梅西与特维斯等不同，梅西从小就在西班牙踢球，受到的是拉马西亚足球文化的熏陶。其对于阿根廷足球的理解并不深刻，对南美球员踢球风格了解的甚少。从今天场上的情况来看，南美球员，甚至玻利维亚这样非足球强国国家的队员，对梅西的防守都要比欧洲球员到位。梅西在欧洲成长，突破欧洲球员的防线早有心得，但是南美球员的防守风格还是让梅西吃了不少苦头。梅西需要及时做出改变。需要适应南美足球的风格，需要去主动适配队友。如果梅西还想着2014年的世界杯，那么就应该在这方面多花些心思。否则还不如干脆退出阿根廷国家队得了，因为看不到赢得希望，这样也避免总是担当输球替罪羊。

其实作为阿根廷队的忠实球迷，我还是希望阿根廷能走到最后的。如果这里的”牢骚“能给阿根廷，能给梅西换来一座金光闪闪的美洲杯的话，那么我愿意再写上一万字。阿根廷的慢热也许未必不是一件好事，想想1998和2002的阿根廷，都是大热，结果死的很惨，而2010的西班牙却笑到了最后。中国有句俗话：先赢的是纸，后赢的才是钱。希望慢热的阿根廷后续能给我们带来惊喜。