简介
为什么 C 语言使用如此广泛呢？我认为原因有两个
- 有着远优于大部分其他语言的程序精确控制能力，C 语言在设计上对平台独立的低层次汇编指令进行了适度的抽象，在大多数情况下，它的代码可以直接映射到硬件平台上的机器指令。因此，我们能够更加灵活地控制程序的具体表现行为。比如可以直接控制代码中某个变量值的存放位置，视情况来决定将它存放在栈内存中，还是寄存器中。在某些特殊场景下，我们甚至可以直接在 C 代码中嵌入汇编代码
- 高效的运行时性能。
我们知道，c 语言代码gcc编译后可以直接执行，其语言与汇编代码具有比较直接的对应关系，笔者个人感觉C比汇编语言主要增强了两点：
- 变量的概念，内存分配变成了变量声明。
- 函数的概念，栈 + cpu出入栈寄存器 + 指令 封装出了函数概念，使得代码有机会（低水平的）模块化编程，简化了大规模开发的复杂度。
变量
位（bit）是计算机中最小的存储单位，字节是最小的可寻址单位
- C 标准中规定，int 类型的大小为执行环境架构体系所建议的自然大小。而对于 Rust 和 Java 这些语言来说，它们的语言标准中直接规定了各类型的具体大小。编译器作为编程语言与硬件体系之间的抽象层，它可以确保上层类型在被编译到机器指令时，不会给程序的实际运行带来可观测的差异。
- 在 C 语言中，通过内联方式直接写到源代码中的字面量值一般被称为“常量”。使用 const 关键字修饰的变量定义语句，表示对于这些变量，我们无法在后续的程序中修改其对应或指针指向的值。因此，我们更倾向于称它们为“只读变量”，而非常量，编译器通常不会对只读变量进行内联处理。
对于大多数计算机而言，通常其内部会使用补码（Two’s-complement）的格式来存放有符号整数，使用直接对应的二进制位格式来存放无符号整数，使用 IEEE-754 标准编码格式来存放浮点数，也就是小数。使用补码来存放有符号整数的一个优点是，CPU 在针对有符号数进行加减法计算时，不需要由于加数的符号性不同而采用多个底层加法电路，这样便可减轻电路设计的负担，另一方面也可以降低 CPU 的物理尺寸。补码的英文名称是 two’s-complement，可直译为“对数字 2 的补充”。PS：补码 的内涵非常多
变量数据的存储
- 初始化的全局变量和静态变量，这类变量的值具有与应用程序同样长的生命周期，其值通常会被存放到进程 VAS（Virtual Address Space，虚拟地址空间）内的 .data 中。未初始化的全局变量和静态变量存放到进程 VAS 的 .bss中。
- 局部变量是我们在编写程序时最常使用的一种变量形式。一般来说，这些变量将被存放在寄存器或应用程序 VAS 的栈内存中，具体使用哪种方式则依赖于编译器的选择。
- 通过 malloc、calloc 等标准库函数创建的内存块中所包含的数据存放到进程 VAS 堆内存中。
- 由于常量本身的不可变特征，它们会按照数据的大小和类型被选择性存放到进程 VAS 的 .rodata 以及 .text 中。其中，.rodata 用于存放只读（Read-only Data）数据，而 .text 通常用于存放程序本身的代码。
- 在 C 语言中，每一个自定义枚举类型中的枚举值，都是以 int 类型的方式被存储的
- 结构只是对其内部所包含各类数据的一个封装，因此从编译产物的角度来看，只需要把它封装的这些数据连续地存放在内存中即可，细节上会考虑“数据对齐”。因此，此时的结构大小也会被作为 sizeof 运算符的最终计算结果。
运算
- 算数、关系、位、赋值这四类运算符在经过编译器处理后，一般都可以直接对应到由目标平台上相应机器指令组成的简单计算逻辑。
- 逻辑与运算符并没有可与之直接对应的汇编指令。并且，为了满足“短路”要求，编译器在非优化的实现中通常会使用条件跳转指令，比如 je。
- 对于取地址运算符 “&”，实际上它一般会直接对应到名为 lea 的汇编指令。这个指令的全称为 “Load Effective Address”，顾名思义，它主要用来将操作数作为地址，并将这个地址以值的形式传送到其他位置。 而解引用运算符 “*”的行为与取地址运算符完全相反。当需要对位于某个地址上的值进行传送时，我们可以直接使用 mov 指令。
- sizeof 运算符是一个编译期运算符，这意味着编译器仅通过静态分析就能够将给定参数的大小计算出来。运算符在编译过程中得到的计算结果值，将会以字面量值的形式直接“嵌入”到汇编代码中使用。
- 强制类型转换运算符，将变量 n 的值类型由原来的 int 转换为了 short。当 mov 指令将变量 n 的值移动到变量 f 所在的内存区域时，它仅移动了这个值从低位开始一个 WORD，即 16 位大小的部分。
- 循环语句和 if 语句的秘密在于比较指令和有条件跳转指令（jmp是无条件跳转指令），它们都用到了 EFLAGS 寄存器。
为什么会有头文件
代码分拆，再通过编译器 + 方法声明（符号引用） 整合起来：
- 项目大了，一个.c 文件写不下，所以分成好几个.c 文件
- a.c 里有一个hello 方法, b.c 怎么知道并使用呢？b.c 可以先声明 有一个hello 方法，根据hello 方法声明找 hello 方法定义的工作交给编译器。编译器在编译b.c的时候会生成一个符号表（symbol table），像“void hello()”这样的看不到定义的符号，就会被存放在这个表中。在进行链接的时候，编译器就会在别的目标文件中去寻找这个符号的定义。
- 这里提到了两个概念，一个是“定义”，一个是“声明”。简单地说，“定义”就是把一个符号完完整整地描述出来：它是变量还是函数，返回什么类型，需要什么参数等等。而“声明”则只是声明这个符号的存在，即告诉编译器，这个符号是在其他文件中定义的，我这里先用着，你链接的时候再到别的地方去找找看它到底是什么吧。
- 如果hello 方法比较热门，在很多c 文件里都有用到了，那就要多次在使用方那里声明 hello 了。并且，使用hello 方法的人 不一定是hello 的作者，对hello 的声明可能会写错。
- 我们可以把hello 声明语句先写好，放在一个文件里，等到程序员需要它们的时候，就把这些东西全部copy进他的源代码中。
- 头文件便可以发挥它的作用了。所谓的头文件，其实它的内容跟.cpp文件中的内容是一样的，都是 C++的源代码。但头文件不用被编译。我们把所有的函数声明全部放进一个头文件中，当某一个.cpp源文件需要它们时，它们就可以通过一个宏命令“#include”包含进这个.cpp文件中，从而把它们的内容合并到.cpp文件中去。当.cpp文件被编译时，这些被包含进去的.h文件的作用便发挥了。
头文件的一个重要目的就是为了能够提供一套对外稳定的接口文档，供其他程序使用已经写好的 C 代码实现，以实现代码重用。但为什么其他语言没有借鉴类似的方式，这就说明这种方式并非一种好的设计。Why are header files bad design?
预处理
预处理器是在编译之前执行一段程序，可以部分的改变我们所写的程序。预处理只有十来个指令，也没有特别严谨的“语法”，但它仍然是一套完整自洽的语言体系，使用预处理也能够实现复杂的编程，解决一些特别的问题——虽然代码可能会显得有些“丑陋”“怪异”。预处理阶段编程的操作目标是“源码”，用各种指令控制预处理器，把源码改造成另一种形式，就像是捏橡皮泥一样。
- 预处理指令都以符号“#”开头，虽然都在一个源文件里，但它不属于 C++ 语言，它走的是预处理器，不受 C++ 语法规则的约束。一般来说，预处理指令不应该受 C++ 代码缩进层次的影响，不管是在函数、类里，还是在 if、for 等语句里，永远是顶格写。
# // 预处理空行 #if __linux__ // 预处理检查宏是否存在 # define HAS_LINUX 1 // 宏定义，有缩进 #endif // 预处理条件语句结束 # // 预处理空行 - 预处理暂时没有办法调试，不过可以让 GCC 使用“-E”选项，略过后面的编译链接，只输出预处理后的源码。
g++ test03.cpp -E -o a.cxx，多使用这种方式，对比一下源码前后的变化，你就可以更好地理解预处理的工作过程了。 - “#include”可以包含任意文件，所以可以写一些小的代码片段，再引进程序里；比如说，有一个用于数值计算的大数组，里面有成百上千个数，放在文件里占了很多地方，特别“碍眼”：
static uint32_t calc_table[] = { // 非常大的一个数组，有几十行 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, ... };这个时候，你就可以把它单独摘出来，另存为一个“*.inc”文件，然后再用“#include”替换原来的大批数字。这样就节省了大量的空间，让代码更加整洁。
static uint32_t calc_table[] = { # include "calc_values.inc" // 非常大的一个数组，细节被隐藏 }; - 预处理变量 有两种状态：已定义和未定义。#define 指令把一个名字设定为预处理变量， #ifdef 和 #ifndef 用来检查预处理变量是否已定义。一旦检查结果为真，则执行后续操作直至遇到 #endif 指令为止。
编译
编译是预处理之后的阶段，它的输入是（经过预处理的）C++ 源码，输出是二进制可执行文件（也可能是汇编文件、动态库或者静态库）。和预处理阶段一样，在这里你也可以“面向编译器编程”，用一些指令或者关键字让编译器按照你的想法去做一些事情。
#include、#define 都是预处理指令，是用来控制预处理器的。有没有用来控制编译器的“编译指令”呢？到了 C++11，标准委员会终于认识到了“编译指令”的好处，于是就把“民间”用法升级为“官方版本”，起了个正式的名字叫“属性”。你可以把它理解为给变量、函数、类等“贴”上一个编译阶段的“标签”，方便编译器识别处理。
[[noreturn]] // 属性标签
int func(bool flag){ // 函数绝不会返回任何值
throw std::runtime_error("XXX");
}
几个比较有用的（全部属性可参考GCC 文档）。
- constructor：函数会在 main() 函数之前执行，效果有点像是全局对象的构造函数。
- destructor：函数会在 main() 函数结束之后执行，有点像是全局对象的析构函数。
- hot：标记“热点”函数，要求编译器更积极地优化。
ELF
使用“头部（header）”来保存可执行文件的基本信息。而其他数据则按照功能被划分在了以 Section 或 Segment 形式组织的一系列单元中。
// elf.c
#include <stdio.h>
int main (void) {
const char* str = "Hello, world!";
printf("%s", str);
return 0;
}
操作系统通过 Magic 字段来判断该文件是不是一个标准的 ELF 格式文件，该字段一共长 16 个字节，每个字节代表着不同含义。ELF 头中还包含有 ELF 文件类型、程序的入口加载地址（0x4004b0），即程序运行时将会执行的第一条指令的位置，以及该可执行文件适用的目标硬件平台和目标操作系统类型等信息。ELF 作为一种文件格式，不仅在可执行文件中被使用，静态链接库、动态链接库，以及核心转储文件等也都可以采用这种格式。
ELF 文件格式的基本组成结构可以被划分为 ELF 头、Section 和 Segment 三大主要部分。其中，各个 Section 中包含有按照功能类别划分好的、用于支撑 ELF 功能的各类数据。这些数据共同组成了 ELF 文件的静态视图，以用于支持 ELF 文件的链接过程。而众多的 Segment 则组成了 ELF 文件的动态视图，该视图描述了 ELF 文件在被操作系统加载和执行时，其依赖的相关数据在进程 VAS 内的分布情况。
在 ELF 格式中，Section 用于存放可执行文件中按照功能分类好的数据，而为了便于操作系统查找和使用这些数据，ELF 将各个 Section 的相关信息都整理在了其各自对应的 Section 头部中，众多连续的 Section 头便组成了 Section 头表。Section 头表中记录了各个 Section 结构的一些基本信息，例如 Section 的名称、长度、它在可执行文件中的偏移位置，以及具有的读写权限等。而操作系统在实际使用时，便可直接从 ELF 头部中获取到 Section 头表在整个二进制文件内的偏移位置，以及该表的大小。在 ELF 格式中，众多的 Section 组成了描述该 ELF 文件内容的静态视图。
众多的 Segment 则组成了描述可执行文件的动态视图。每个 Segment 也都有其对应的头部，以描述该 Segment 的一些基本信息，我们一般将其称为 Program 头。Program 头中包含着各个 Segment 的类型、偏移地址、大小、对齐情况，以及权限等信息。其中，被标注为 “LOAD” 类型的 Segment 将会在程序运行时被真正载入到进程的 VAS 中，而其余 Segment 则主要用于辅助程序的正常运行（比如进行动态链接）。
通常来说，各个 Segment 与 Section 之间会有一定的对应关系。
其它
void* 是一种特殊的指针类型，可用于存放任意对象地址，不同的是，我们对该地址中到底是个什么类型的对象并不了解。利用void* 指针能做的事儿比较有限：拿它和别的指针比较、作为函数的输入输出，或者赋给另外一个void* 指针，不能直接操作 void* 指针所指的对象。
redis 源码的部分体会
带有详细注释的 Redis 3.0 代码（annotated Redis 3.0 source code）
Redis是一个用ANSI C 编写的开源数据结构服务器。Redis的代码非常容易读懂，代码写的很整洁，并且代码量相对较小（4.5w行，其实也不是很小）。大部分都是单线程的，几乎不依赖其它库。
Redis 没有直接使用 C 语言传统的字符串表示（以空字符结尾的字符数组，以下简称 C 字符串）， 而是自己构建了一种名为简单动态字符串（simple dynamic string，SDS）的抽象类型，sds 头文件
struct sdshdr {
int len;
int free;
char buf[];
};
static inline size_t sdslen(const sds s) {
struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
return sh->len;
}
static inline size_t sdsavail(const sds s) {
struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
return sh->free;
}
sds sdsnewlen(const void *init, size_t initlen);
sds sdsnew(const char *init);
sds sdsempty(void);
size_t sdslen(const sds s);
sds sdsdup(const sds s);
void sdsfree(sds s);
size_t sdsavail(const sds s);
sds sdsgrowzero(sds s, size_t len);
sds sdscatlen(sds s, const void *t, size_t len);
sds sdscat(sds s, const char *t);
sds sdscatsds(sds s, const sds t);
sds sdscpylen(sds s, const char *t, size_t len);
sds sdscpy(sds s, const char *t);
...
非常优雅的代码，定义一个结构体，包含各种方法，sds 作为大部分方法的第一个参数，以一个java 开发者的视角来看，这就是在定义一个对象。PS：很多语法、语言特性可能就是在一系列最佳实践的基础上发现的。笔者日常码代码也有类似的体会：每一个细节都保持优雅，自然可以发现重构、复用的地方。