关于使用C语言开发的那些事

我们从一个简单的例子出发:

// eatc.c
#include <stdio.h>

int main(int argc, char **argv) {
  printf("Eat something!\n");
  return 0;
}

在得到源代码后, 就是编译生成程序了: gcc eatc.c -o eatc, 这命令会发生以下过程,

我们这里的目标是研究预处理(CPP)这个阶段发生了什么.

当我们在编译时加多一个 --save-temps 选项:

gcc --save-temps eatc.c -o eatc

可以得到 eatc.i 和 eatc.s 两个额外的文件, 这个选项是编译过程中生成的中间文件给保留下来,

其中 eatc.s 是源代码对应汇编码, 这块已经能够单独出一门课程了, 这里不深入研究.

我们的目标是 eatc.i 文件, 这个文件其实就是对应 CPP 阶段生成的 .c 文件,

对比 eatc.c 而言, eatc.i 在 GCC 眼中 eatc.i 才是纯 C 文件 (pure c file).

我们可以简单地把预处理理解为源代码的文本处理:

• 移除 .c 文件里面的注释;
• 使用预处理器的指令生成文本, 或者定义宏(Macro);

• 把宏替换成对应的文本;

  
  

  预处理指令都是 # 开头的, 这个例子只使用了 #include (也可以写成 # include 这样子) 一个预处理指令, 它的作用只是把指定的文件内容复制插入到它的位置上而已, 这点可以从 eatc.i 和 stdio.h 进行内容对比一探究竟.

  #include <stdio.h> 就是先从系统预设的路径查找 stdio.h, 这个路径在 Linux 上通常都是 /usr/include 这个目录下,

  我本人电脑上 stdio.h 的完整路径就是 /usr/include/stdio.h.

  接下来我们对比一下 eatc.i 和 stdio.h 两者头部的内容差别,

  eatc.i 的头部:

  # 0 "eatc.c"
  # 0 "<built-in>"
  # 0 "<command-line>"
  # 1 "/usr/include/stdc-predef.h" 1 3 4
  # 0 "<command-line>" 2
  # 1 "eatc.c"
  
  # 1 "/usr/include/stdio.h" 1 3 4
  # 27 "/usr/include/stdio.h" 3 4
  # 1 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h" 1 3 4
  # 33 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h" 3 4
  ...
  

  /usr/include/stdio.h 的头部:

  /* Define ISO C stdio on top of C++ iostreams.
     Copyright (C) 1991-2022 Free Software Foundation, Inc.
     This file is part of the GNU C Library.
  
     The GNU C Library is free software; you can redistribute it and/or
     modify it under the terms of the GNU Lesser General Public
     License as published by the Free Software Foundation; either
     version 2.1 of the License, or (at your option) any later version.
  
     The GNU C Library is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
     Lesser General Public License for more details.
  
     You should have received a copy of the GNU Lesser General Public
     License along with the GNU C Library; if not, see
     <https://www.gnu.org/licenses/>.  */
  
  /*
   *      ISO C99 Standard: 7.19 Input/output     <stdio.h>
   */
  
  #ifndef _STDIO_H
  #define _STDIO_H        1
  
  #define __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION
  #include <bits/libc-header-start.h>
  ...
  

  可以看到除了被移除的注释和一些陌生的指令以外, 感觉上是差不多的,

  这点可以从 eati.i 的 # 1 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h" 1 3 4 这种注释看出来.

  如果觉得这不太好看出来的话, 你可以把例子改成如下:

  // eatc.c
  #include <stdio.h>
  
  int main(int argc, char **argv) {
    printf("Eat something!\n");
    return 0;
  #include "right-bracket"
  

  // right-bracket
  }
  

  再次检查 eatc.i 文件的尾部:

  # 4 "hello-world.c"
  int main(int argc, char **argv) {
    printf("Eat something!\n");
    return 0;
  # 1 "right-bracket" 1
  }
  # 8 "hello-world.c" 2
  

  多了一行处理日志的注释 # 1 "right-bracket" 1, 并且我们的程序也能通过编译以及运行.

  
  

  接下来解释一下什么是宏, 我们简单地把宏看作一个可以用来生成文本的 文本模板,

  我认为, 要理解这个概念就需要以带参数的宏来作为起点例子.

  我们把上面的 eatc.c 改写成用参数宏来生成函数 main 的定义:

  // eatc.c
  #include <stdio.h>
  
  #define MAIN_CLOSURE(...) int main (int argc, char **argv ) { __VA_ARGS__ }
  
  MAIN_CLOSURE (
                printf("Eat something!\n");
                return 0;
                )
  

  我们可以对比一下前后两次编译得 eatc.i 里的函数 main 长什么样子的,

  第一次生成的:

  # 4 "hello-world.c"
  int main(int argc, char **argv) {
    printf("Eat something!\n");
    return 0;
  }
  

  第二次生成的:

  # 6 "hello-world.c"
  int main (int argc, char **argv ) { printf("Eat something!\n"); return 0; }
  

  可以看到两者的格式上虽然有些不太一样, 但定义可以说是一模一样的.

  第二个版本中 eatc.c 的宏 MAIN_CLOSURE 就是把 int main (int argc, char **argv ) { __VA_ARGS__ } 这一部分文本作为一个模板,

  在预编译阶段里面就往模板里面的 __VA_ARGS__ 这个位置插入文本, 而这些被插入的文本就是作为 MAIN_CLOUSRE 参数传入的,

  这里例子里被插入的文本就是 printf("Eat something!\n"); return 0;.

  MAIN_CLOSURE 还不是一个普通的参数宏, 它是一个可变参数宏, __VA_ARGS__ 就表示那个可变参数 ....

  宏也是可以不带参数的, 初学者很容易看见 #define NUM 1 这种简单的宏, 我之所以不以简单的例子来开始, 是因为很多初学者都以为这种简单宏看作常量的定义,

  然而把宏改成 #define NUM 3 - 2, 再带着这种想法去使用 NUM 时就导致程序发生意想不到的 bug.

  int res = NUM * 4;
  

  在两个不同的宏定义下, 预处理得到的结果是不一样的:

  int res = 1 * 4;
  

  int res = 3 - 2 * 4;
  

  导致结果不一样的原因正是是初学者都以为宏是普通的变量定义, 而不是文本生成.

  不过哪怕一开始强调是文本生成, 初学者也不一定能理解, 因此先解释清楚文本生成是什么一个概念才是最重要的,

  而本人认为解释这一概念最应该先找一个能够区分得了变量定义和文本生成两者差别的例子, 那么带参数的宏不就最能体现吗?

  至于那些说函数和带参数的宏也很像的人, 我想说的是, 难道函数能够做到像 MAIN_CLOSURE 玩弄源代码那种事情吗?

  还需要声明一点的是, 预处理器本身体不属于 C 语言的定义里头的, 它是属于编译器, 因此你用别的编译器是, 所支持的预处指令/宏定义都是不同的,

  详情参考 GCC的 CPP 文档.

  最后再注意的一点是, 定义宏时需要严格遵守格式: #define SIMPLE_MACRO_NAME text 或 #define ARG_MACRO_NAME(arg1, arg2, ...) text 这种格式,

  因为宏本身就是一个文本模板, SIMPLE_MACRO_NAME 和 text 之间要用一个空格隔开, 多余的空格算到 text 里面,

  而带参数的宏 ARG_MACRO_NAME 和它后面的参数列表之间是不能有空格的, 否者就是 SIMPLE_MACRO_NAME 那种情况了;

  此外, text 是只能占一行的, 如果你觉得一行不好写实在要换行, 可以告诉编译器: "我现在手动换行, 你后面要把它拼成一行",

  我以改写前面的 MAIN_CLOSURE 作为例子:

  #define MAIN_CLOSURE(...) int main (int argc, char **argv ) {   \
      __VA_ARGS__                                                 \
        }
  

通常情况下, 头文件(.h)的内容都是一些宏/变量的定义以及变量/函数的声明(declarations),

.c 文件用来存放对应头文件里变量/函数对应的实现(implementation), 或者说定义(definitions).

事实上你完全把整个项目的源代码可以在一个文本文件里面, 声明和定义可以不分开, 都能够编译出一个能运行的程序.

在 GCC 眼中, 源码文件的 .h 和 .c 后缀都是没有意义上不同的, 它不会知道 .h 就是主要用于提供声明, .c 提供定义.

那么为什么开发人员需要这种区分呢? 这就要从一个最简单且完整的 C 程序说起:

// simple-c.c
// 定义函数
int func ( int a, int b ) {
  return a + b;
}

// 程序入口
int main( int argc, char **argv ) {
  func( 1, 2 ); // 使用定义的函数
  return 0;
}

或者是:

// simple-c.c
// 程序入口
int main( int argc, char **argv ) {
  func( 1, 2 ); // 使用定义的函数
  return 0;
}

// 定义函数
int func ( int a, int b ) {
  return a + b;
}

这两者实际上都能编译通过并运行程序, 学过其它语言的人可能觉得这没什么问题, 但是对于编译器则不一定了,

本人用的是 GCC 11.2.0 默认的 C 标准 ISO C17, 在编译时, 后者比起前者会多出一个警告:

simple-c.c: In function ‘main’:
simple-c.c:4:3: warning: implicit declaration of function ‘func’ [-Wimplicit-function-declaration]
4 |   func(1, 2);
          |   ^~~~

这是因为 GCC 是逐行编译导致的, 它每处理一条句时都会对遇到里面的变量/函数名字查找到其对应的信息,

检测这个变量是什么类型, 这个函数接收什么样的参数以及返回什么样的值, 编译器需要根据这些信息估算要使用的内存空间以及评估你的程序是否存在什么问题.

但是在第二种的情况下编译时, GCC 是先编译 main, 在 main 里面找 func 的定义, 这个时候编译器还不清楚 func 长什么样,

于是它只能根据上下文"猜"出 func 的样子.

解决这个警告很简单:

// simple-c.c
// 在调用func前为其进行声明
int func( int, int );

// 程序入口
int main( int argc, char **argv ) {
  func( 1, 2 ); // 使用定义的函数
  return 0;
}

// 定义函数
int func ( int a, int b ) {
  return a + b;
}

我们姑且先把这一次的版本叫做最终版吧, 第一个版本叫做初版.

可以看到最终版里面的声明只提供函数的名字, 其参数类型以及返回值, 这些信息是必须的, 后续的定义需要和这些关键信息要保持一致;

而参数名则是可选信息, 即便是写了, 也不需要和定义里头的参数名一样, 但为了代码可读性还是建议写上.

我们可以反过来只提供声明不提供定义, 看看编译会发生什么?

这里以最终版为例, 把 func 注释掉后会得到一个链接器报的错误:

/usr/bin/ld: /tmp/ccxdFKZ5.o: in function `main':
simple-c.c:(.text+0x1e): undefined reference to `func'
collect2: error: ld returned 1 exit status

在 C 语言里面, 如果声明前面没有加任何 extern 和 static 关键字, 就默认 extern 关键字,

extern 就是告诉编译器模块引用的定义可能由别的模块提供;

static 关键字则告诉编译器模块内的定义不能被其它模块引用.

由于声明默认是 extern 关键字, 因此, extern 的一般是用来暗示引用其它模块中的定义, 没有实质作用.

回到例子中, 当不在源代码里面提供 func 的定义时, 编译器就会认为 func 的定义会在别的地方,

等编译完了就交给链接器在链接时去找 func 的定义, 由于没有找到对应的定义, 于似乎它报错了.

解决这个问题除了把注释解除掉外, 还可以在使用 GCC 编译时让它链接到一个提供定义的二进制文件, 这种提供定义的二进制文件就是人们口中的库.

库分动态链接库(dynamic link library/shared link library)和静态链接库(static link library),

在 Linux 上静态链接库的后缀是 .a(rchive), 动态链接库的后缀是 .s(hared)o(bject).

链接动态链接库的叫做动态链接, 而把多个二进制文件链接为一体的链接方式就叫静态链接, 静态链接不一定非得使用静态库的,

动态链接得到的程序会在运行前寻找动态库并且加载, 如果找不到动态库就运行不起来;

静态链接得到的程序本身就是完整的, 因此是可以直接运行的, 然而静态链接生成的程序本体比动态链接的要大.

我们基于前面最终版的代码拆分一下用于后续演示两种链接:

// simple-c.c
extern int func( int, int );

int main(int argc, char **argv) {
  func(1, 2);
  return 0;
}

// simple-c-func.c
int func ( int a, int b ) {
  return a + b;
}

静态链接 有两种方法:

• 静态链接-1

  gcc -o simple-c simple-c.c simple-c-func.c
  

  这种方法会把中间生成若干个 .o 的目标文件, 然后链接器再它们链接起来得到一个程序, 这个过程其实并未使用到静态库.

  这条命令等价于以下:

  gcc -c simple-c-func.c
  gcc -c simple-c.c
  gcc -o simple-c simple-c.o simple-c-func.o
  

• 静态链接-2

  gcc -c -o simple-c-func.o simple-c-fun.c
  ar rcs libsimple-c-func.a simple-c-func.o
  gcc -o simple-c simple-c.c -lsimple-c-func -L.
  

  这里的 -lsimple-c-func 就是让 simple-c 和 simple-c-func.a 进行链接,

  GCC 的 -l 选项就是用来指定要链接的链接库名; -L 指定在哪个路径下找链接库, 如果库在系统默认位置上, 那么不需要该选项指定.

  
  

  动态链接 如下:

  gcc -shared simple-c-func.c -o libsimple-c-func.so
  gcc -o simple-c simple-c.c -lsimple-c-func -L. -Xlinker -rpath -Xlinker .
  

  需要注意这里用上了 GCC 的 -Xlinker 选项来给 ld 传入 -rpath .,

  由于编译得到的程序的文件格式是 ELF, 并且我们这个库并非在系统搜索的路径里面,

  因此我们需要告诉 ld 该链接生成的程序在 运行时 需要从自身当前位置查找 libsimple-c-func.so,

  如果 libsimple-c-func.so 是位于 ld 默认的库查找路径上, 那么最后的编译命令可以写成:

  gcc -shared simple-c-func.c -o libsimple-c-func.so
  gcc -o simple-c simple-c.c -lsimple-c-func
  

  
  

  这里有一个地方值得思考一下, 动态和静态两种链接除了生成库的方式不同以外, 在生成编译程序的命令上都是一样的,

  如果 ld 默认的库查找路径上同时存在一个库的动静态两个版本的库, ld 又是如何选择的呢?

  在 GCC man page 里面可以看到 -l 选项说明里面有这么一段描述:

  Static libraries are archives of object files, and have file names like liblibrary.a. Some targets also support shared libraries, which typically have names like liblibrary.so. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.

  可以看到默认情况下是默认链接动态库, 而这个 -l 选项是直接传给链接器的, 所以链接器也是这么处理的.

  GCC 启动时会调用一个名叫 collect2 功能, 这个功能调用 ld 来生成一张符号表用于查找定义以及进行链接, 它就是一个链接器的封装.

  可以在编译时给 GCC 添加一个 -v 选项来看看 GCC 给 ld 传了什么参数, collect2 接受的参数就是 ld 的参数.

  
  

  还有另外一个地方值得思考, 现在我们的 simple-c-func 已经是一个库了, 也就是说可以用在其它程序的源代码上了.

  但这有一个问题, 每次用到别的程序上时, 我们都要在调用了函数 func 的源代码里写上 int func(int, int); 这么一句,

  万一 simple-c-func 提供了不止 func 一个函数呢, 岂不是要写很多个声明吗?

  这就是头文件存在的意义了: 把所有对应定义的声明写到一个头文件里, 在调用这些定义之前先 #include 该头文件.

  我们都知道 #include 本质上就是复制文本, 所以 #include 头文件这操作很好理解.

  因此, 上面的最终版代码可以拆开成三份来发布:

  // simple-c.c
  #include "simple-c-func.h"
  
  int main(int argc, char **argv) {
    func(1, 2);
    return 0;
  }
  

  // simple-c-func.h
  #ifndef SIMPLE_C_FUNC_H
  #define SIMPLE_C_FUNC_H
  int func( int, int );
  #endif
  

  // simple-c-func.c
  int func ( int a, int b ) {
    return a + b;
  }
  

  然而只发布源代码的话, 拿到代码的人就不太方便使用了, 一般要提供构建工具的配置文件,构建脚本以及构建说明,

  其中构建说明会描述项目依赖哪些第三方库以及构建步骤, 置文件和脚本通常都是和构建工具配合使用.

  接下来会介绍构建方式, 但在讨论这个话题之前, 我们先回顾一下上个例子 eatc, 它调用了 printf 函数,

  从代码上看, 它貌似是来源于 stdio 库的, 并且链接时是从系统路径上查找库的, 如果是这么想的话就不太对了.

  你没办法在系统路径上找到 libstdio.a 或者 libstdio.so 的文件, 你可以 ldd 命令看一个可执行程序或者动态链接库链接了哪些动态链接库,

  我们对 ldd eatc 之后可以看到以下内容:

  linux-vdso.so.1 (0x00007fff5cba3000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fcd67b000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f2fcd8c3000)
  

  这里引用了一个叫做 libc.so.6 的动态链接库, 而 printf 的实现就是它提供的, libc 就是 C 库, 而这个 C 库是由 GNU实现的,

  我们可以使用 nm 来查看它的符号表:

  nm -Dg /lib/x86_64-linux-gnu/libc.so.6
  

  你可以在里面找到 printf 的符号信息:

  ...
  0000000000060770 T printf@@GLIBC_2.2.5
  ...
  

  当然它也有静态链接库版本, 和 libc.so.6 位于同一个目录下, 名字叫做 libc.a,

  同样也可以用 nm 来列出静态链接库的符号表:

  nm -s /lib/x86_64-linux-gnu/libc.a
  

  我们都知道 .a 文件就是一个由多个 .o 文件组合而成的集合包, 可以使用一下命令看看里面有哪些 .o 文件:

  ar t /lib/x86_64-linux-gnu/libc.a
  

  按照前面的说法个, 在静态链接中 #include "simple-c-func" 对应一个 simple-c-func.o 或者 simple-c-func.a 的话,

  那么 libc.a 是否包含一个 stdio.o 的文件, 并且由它提供 printf 函数呢?

  通过以下命令来查找每个 .o 文件提供的了哪些符号:

  nm -s /lib/x86_64-linux-gnu/libc.a
  

  我们配合 grep 命令可以查找出关于 printf 符号的描述:

  nm -s /lib/x86_64-linux-gnu/libc.a | grep '^printf\s'
  

  然而我们猜错了, 在结果里面可以看到这一部分:

  printf in printf.o
  nm: sysdep.o: no symbols
  nm: sigvec.o: no symbols
  

  是不是有点意外, 虽然 #include <stdio.h> 但 printf 是 printf.o 提供的.

  (看了一眼 glibc 的源代码好像 stdio 是有使用到 printf 的, 我也不太确定).

  如果有兴趣的话, 可以使用以下命令把 printf.o 提取出来:

  ar x /lib/x86_64-linux-gnu/libc.a printf.o --output .
  

C/C++ 语言的声明语法基本上都是一样, 并且都很难阅读, 个人觉得直接看它们的声明语法也不太直观, 你可以在这里找到 C 语言的标准, 看看里面的 Language-Declarations 那一节.

于是搜索了一番 how to read c declarations 看看有没有更加好用的技巧, 结果还真的有: 顺时针螺旋法(. 如果该链接挂了,请阅读这里.)

很多人都说 C 语言的指针很难, 个人认为他们每个人说的难可能实际上都不是指同一个东西.

首先我认为难是因为这两个原因中的任意一个或者全部: 指针的声明难以阅读; 不了解程序的内存管理, 不知道指针就是内存地址.

第一个问题在前面的读懂 C 的声明语法就有答案了,

第二个问题这就需要你去了解汇编语言了, 只有了解 C 源码编译成汇编时指针是什么样的, 才能掌握指针的用法.

指针是 C 这类语言的内存管理之道, 哪怕是深谙用法的老练开发人员也很难确保不会因疏忽导致出现内存安全问题.

新手最常见的疏忽就是使用 malloc 在堆上申请了内存区域却忘记使用 free 进行释放, C++ 里面有 RAII 来解决这个问题,

malloc 会在成功申请空间后返回空间地址, 失败的时候返回 null 指针 (也就是 NULL).

根据 ISO-IEC 9899 的 C standard, 7.20.3.2/2 可以得知 free(NULL) 也是没有问题的.

因此, 在 free 时不需要对 malloc 返回的地址做额外判断.

然而这也没有完全杜绝内存安全问题, 这是因为出现安全问题的原因很多.

通常开发人员会使用一写工具提示哪里出了内存安全问题, 在 Linux/Unix 环境上(Windows 有 WSL)可以使用 Valgrind 来进行检测.

使用的方法很简单, 在编译的时候开启调试信息生成, 比如要对前面的 simple-c 进行检测, 那么就需要这么编译:

simple-c:  simple-c.c simple-c-func.so
gcc -g -o simple-c simple-c.c -lsimple-c-func -L. -Xlinker -rpath -Xlinker .
simple-c-func.so: simple-c-func.c
gcc -g -shared simple-c-func.c -o libsimple-c-func.so

每个编译命令都加载 -g 选项, 否者 Valgrind 就会提示你的源代码的问题在第几行,

最好在加上 -O0 (Letter "O" and Digit Zero) 选项取消优化来保证调试信息达到最精确, 但其实默认优化 -O1 在大部分情况下也够用.

之后就是根据 Valgrind 的信息来修正程序错误了, 因此掌握 Valgrind 的关键是理解其错误信息的含义.

最后, 个人建议任何人都应该仔细看一遍 Valgrind 的上手教程, 特别是 Caveats 部分.

未定义是指语言规范并未说明该情况该如何处理, 这种情况就是未定义行为.

不同的编译器对未定义行为的处理是不一样的, 因此代码里面不要有这种行为,

比如下面这种,

#include <stdio.h>
int main(int argc, char* args[]) {
  int i = 1;
  printf("Unpredictable result: %d\n", (++i) + (++i));
  return 0;
}

GCC 编译得到的程序, 其计算结果是 6; 而 Clang 编译后得到的程序的计算结果是 5.

这是只是其中一种未定义行为, 维基百科上总结其它情况, 有兴趣可以看一下.

按照参数个数来分类的话, C 语言的函数声明共有 4 种.

以声明加法函数 add 为例,

• 带参数类型

  int add (int a, int b);
  

  或者

  int add (int, int);
  

• 禁止调用时被传入参数

  int add (void);
  

  这种声明方法实际上是第一种声明的特例, 调用这种函数的时候不能传入任何参数.

• 不声明任何参数, 但调用时可以传入任意参数

  int add ();
  

  这种声明法一般是搭配 extern 来用, 链接时引用外部的 add 函数,

  而外部的 add 函数参数声明可能会有几种情况, 比如 int add (int, int) 和 int add (int, int, int).

  那么 int add () 这种声明方法就能够很好地兼容这两种情况.

  C 语言的前身是 B 语言, B 语言的函数是没有类型的. C 继承了这点, 只是后来的标准添加了类型支持.

  为了向后兼容已有的旧代码, 编译器就允许这种空参数列表的函数声明. (从这点看, C 语言不折不扣的是一门弱类型语言.)

  拿 GCC 来说, 如果你想编译器严格执行类型检查, 那么在编译时使用 -Wstrict-prototypes 选项提示警告.

  严格上来说这是 K&R C 的语法, 只是对于从 ANSI C 上手的人(本人就是)而言初看不起眼, 细看吓一跳.

  同样的惊喜还出现在函数的定义上, 假设 add 是一个把两个整数相加再返回整数的函数,

  在 K&R C 里面是这么定义的:

  int add (a, b)
       int a;
       int b;
  {
    return a + b;
  }
  

  自己写新项目的话尽量不要这么写, 毕竟这语法不属于 ANSI C 里面, 以后可能要被淘汰.

• 可变参数

  C 语言本身支持定义参数的数量/类型不固定的函数, 这些函数叫做可变参数函数(varargs functions or variadic functions).

  但是 C 语言本身不给函数提供访问可变参数的机制, 因此这方面工作就要交给库来完成了.

  GNU libc 的 stdarg.h 就提供这些功能.

  #include <stdarg.h>
  
  int
  add (int count, ...)
  {
    va_list argp;
    int i = 0;
    int sum = 0;
  
    va_start ( argp, count );      /* Initialize the argument list. */
                                   /* the second of va_start is the name of last argument before arg list. */
  
    for (; i < count; i++ )
      sum += va_arg ( argp, int ); /* Get the next argument value. */
  
    va_end ( argp );               /* Clean up. */
    return sum;
  }
  
  int
  main (void)
  {
    return add ( 4, 1, 0, 3, 4 );
  }
  

  va_start 宏初始化参数列表, 该宏的第二个参数是参数列表之前的一个参数, 这里是 count;

  va_arg 获取列表里面下一个的参数, 其中还得给出该参数的类型, 该例子里面的函数 add 的作用是对所有整数进行求和,

  也就是说所有参数都是 int 类型, 所以例子里面的参数类型是 int.

  va_end 结束参数列表调用, 该宏的参数得和 va_start 的第一个参数对应.

  如你说见, add 需要传入一个 count 来表示参数列表的参数个数, 这是因为没有官方宏/函数来获得参数列表的长度.

  不过有人通过宏来 有限 地提供获取参数列表的长度, 比如:

  #define VA_NUMS_HELPER(_1, _2, _3, _4, _5, _6, N, ...) N
  #define VA_NUMS(...) VA_NUMS_HELPER(__VA_ARGS__, 6, 5, 4, 3, 2, 1, 0)
  

  这个自定义的 VA_ARGS 可以获取到最大长度为 6 的参数列表的长度.

  这个 VA_ARGS 利用了 "可变参数宏可以获得 ... 部分之前的最后一个参数" 的原理以及通过错位传入参数来获得长度.

  VA_ARGS(a, b, c)
  /*
    首先展开为 VA_NUMS_HELPER(a, b, c, 6, 5, 4, 3, 2, 1, 0),
  
    通过观察 VA_NUMS_HELPER 的定义可以发现 (2, 1, 0) 这三个参数就属于 ... 部分,
  
    所以 VA_NUMS_HELPER 宏就被展开成这 3 个参数的前一位 3, 这也正是参数列表 (a, b, c) 的长度.
  */
  

  之所以说是有限, 是因为在 VA_NUMS_HELPER 的宏定义的占位符参数(_1, _2, _3, _4, _5, _6) 是固定编码, 并非动态的,

  你想要测量长度超过 6 的参数列表, 那么就得修改 VA_NUMS_HELPER 的定义.

  因此, 开发人员无法在不改变 VA_NUMS_HELPER 定义的情况下获得任意长度的参数列表.

  那么如何使用这个宏呢? 就以 add 为例, 我们定义一个同名宏 (需要注意同名宏要在定义/声明之后):

  // header.h
  int add (int count, ...);
  #define add(...) add(VA_NUMS(__VA_ARGS__), __VA_ARGS__)
  
  // in some c source files
  add(1, 2, 3);
  

不透明结构体就是把结构体的声明和定义分开, 声明放在头文件(.h)里面, 定义则是放在实现的源文件(.c)里面, 以达到结构体定义可以被隐藏的目的.

假设你现在写了一个程序 A, 定义一个 op_node_s 的结构体, 由于这个结构体设计了一些隐私, 并不想在发布程序 A 时把 op_node_s 的定义也发布出去, 只想让用户使用和它相关的函数.

这种情况下就要使用不透明结构体来解决.

具体做法是把 op_node_s 的定义去掉, 并且为 op_node_s 声明一个新类型 op_node_t, 并把函数的声明中的 op_node_s 替换成 op_node_t.

首先 是头文件 op_node.h, 这里面只放声明.

/* op_node.h */
#ifndef __OP_NODE__H
#define __OP_NODE__H
typedef struct op_node_s op_node_t;

int op_node_new(op_node_t **pp_op_node);
void op_node_free(op_node_t *p_op_node);
void op_node_set_value(op_node_t *p_op_node, int value);
#endif

其次 是 op_node.c, 这里面是头文件声明的相关实现, 我们的 op_node_s 的定义就在这里.

/* op_node.c */
#include <stdlib.h>
#include "op_node.h"

struct op_node_s {
  int value;
};

int op_node_new(op_node_t **pp_op_node)
{
  (*pp_op_node) = (op_node_t *)malloc(sizeof(op_node_t));
  if (NULL == *pp_op_node) {
    return -1;
  }
  (*pp_op_node)->value = 0;
  return 0;
}

void op_node_free(op_node_t *p_op_node)
{
  free(p_op_node);
}

void op_node_set_value(op_node_t *p_op_node, int value)
{
  p_op_node->value = value;
}

在为不透明结构体提供定义时, 需要注意一点: 不建议使用在定义结构体时引用结构体自己的类型声明(甚至是头文件里面的任何声明).

假设我们要定义的不透明结构体 op_node_s 是一个递归结构体, 如下:

struct op_node_s {
  int value;
  op_node_s *next;
};

那么不要定义成:

struct op_node_s {
  int value;
  op_node_t *next;
};

这么做的目的是为了不必要的 #include 指令.

有时候你可能想然 op_node_s 的定义在程序 A 的其它地方被使用, 人们通常会把结构体的定义单独定义在 _private.h 后缀的文件中,

在发布程序的其它地方引入该文件, 换在这里的话, 文件的名字正常来说就是 op_node_private.h;

如果把 op_node_s 修改成了 "不建议" 的形式, 那么每次引入 op_node_private.h 时就得同时引入 op_node.h, 毕竟 op_node_t 是声明在 op_node.h 里面.

/* op_node_private */
#ifndef __OP_NODE_PRIVATE__H
#define __OP_NODE_PRIVATE__H
struct op_node_s {
  int value;
};
#endif

最后把 op_node.c 修改如下:

#include <stdlib.h>
#include "op_node.h"
#include "op_node_private.h"

int op_node_new(op_node_t **pp_op_node)
{
  (*pp_op_node) = (op_node_t *)malloc(sizeof(op_node_t));
  if (NULL == *pp_op_node) {
    return -1;
  }
  (*pp_op_node)->value = 0;
  return 0;
}

void op_node_free(op_node_t *p_op_node)
{
  free(p_op_node);
}

void op_node_set_value(op_node_t *p_op_node, int value)
{
  p_op_node->value = value;
}

最后 在发布阶段时, 你要把 op_node.c 编译成一个链接库 O, 把它和 op_node.h 一起打包发布,

用户只需做两件事情就可以调用你的发布功能了:

1. 引入 op_node.h
2. 运行程序时链接你发布的库 O

/* main.c: test op_node */
#include "op_node.h"

int main(int argc, char **argv)
{
  op_node_t *node;
  op_node_new(&node);
  op_node_set_value(node, 10);
  op_node_free(node);
  return 0;
}

这里需要着重对该使用例子进行一下说明, 在定义/声明不透明结构体时, 只能定义/声明不透明结构体的指针,

也就说 op_node_t node 是不行的, 但 op_node_t *node 是可以的,

这是因为此时结构体的实现是被隐藏了的, 而引入的头文件 op_node.h 里面只有结构体的声明,

编译器是无法在结构体定义缺失的情况下为不透明结构体的变量分配空间, 但编译器还是知道指针的大小的,

同时这也禁止在使用中直接进行 malloc(sizeof(op_node_t)) 这样的内存分配操作,

只能在 op_node.c 提供的 op_node_new 函数来完成;

但是直接使用 free(node) 操作是没问题的

因为同样的理由, 无法直接通过 node 来操作结构体的成员 value,

编译器会提示 Incomplete definition of type 'struct op_node_s' 错误,

只能通过 op_node.c 里面提供的函数 op_node_set_value 来操作,

所有对于结构体成员的操作都受限于 op_node.c 有没有提供相应的实现,

比如这里因为 op_node.c 没有提供相应函数而无法获取 node 的 value 值.

现实中很多软件都使用了不透明结构体, 让使用者专注于 API 而不是结构体的细节.

其中的一个例子就是 SQLite 3, 它的 sqlite 类型就是一个不透明结构体.

一个联合体是一个可以储存任意类型的内存区域. 比如一个联合体可以储存 int 或 char 类型, 那么这个联合体的大小就是 sizeof(int),

因为需要在保证能够储存 char 的同时保证储存 int 的可能性.

union ExampleUnion { int i; char c };

union ExampleUnion example = { .i=100 };

example.c = 'c';

这个例子里面对 c 成员进行赋值会对 i 成员已存在的数据造成"破坏", 所以, 在同一时间内只能使用一个联合体成员进行数据读写.

相比结构体, 联合体更加节省内存. 其次, 它还有一个妙用.

C 语言的函数无法返回多种可能类型的返回值, 然后有时就是有这种需求.

比如说有一个函数, 接受两个 int 型参数, 进行除法运算并返回结果. 按照结果而言, 分三种可能:

一是两个参数满足整除, 那么结果就是 int;

二是不满足整除, 那么结果就是 float/double;

三是除数是 0, 那么不应该有结果, 或者结果为无限大.

这种时候可以使用标签联合体来解决.

union divResult {
  int i;                        /* 第一种情况 */
  float f;                      /* 第二种情况 */
  char c;                       /* 第三种情况, 我们用一个字符来表示计算无结果, 其实可以不需要该成员 */
};

typedef struct {
  enum { T1, T2, T3 } type;     /* T1, T2, T3 分别代表上述三种情况, 这三个就是标签 */
  union divResult value;
} divResult_t;

divResult_t div(int a, int b)
{
  if (b == 0) {
    return (divResult_t){ .type=T3, .value={ .c='I' } };
  } if ((a % b) == 0 ) {
    return (divResult_t){ .type=T1, .value={ .i=(a / b) } };
  } else {
    return (divResult_t){ .type=T2, .value={ .f=((float)a / b) } };
  }
}

int main()
{
  divResult_t res = div(3, 2);
  if (T2 == res.type) {
    printf("float result: %.2f\n", res.value.f);
  }

  divResult_t res2 = div(4, 2);
  if (T1 == res2.type) {
    printf("integer result: %d\n", res2.value.i);
  }

  divResult_t res3 = div(4, 0);
  if (T3 == res3.type) {
    printf("Cannot devided by Zero\n");
  }
}

实际上返回多种可能类型的解决方法还有很多, 比如可以使用结构体来替代联合体(, 相比联合体浪费空间); 还能使用 void * 或者 uintptr 来替代(, 后续根据类型解引).

https://hackaday.com/2019/09/24/asynchronous-routines-for-c/

https://en.wikipedia.org/wiki/X_macro

• 良好的 ABI 兼容性

  C++ 有着复杂的名字改编(name-mangling), 而名字改编又没有规范,

  这导致了不同编译器生成的二进制文件的符号是不确定的, 也就是说不同编译器之间生成的二进制文件无法彼此调用, 这就是所谓 C++ 的 ABI 不兼容.

  我们都知道 C++ 有命名空间以及函数重载, C++ 也就是说可以有很多个同名变量, 函数, 而学过汇编的都知道,

  一个程序里面是不可能有多个同名符号的, 因此根据 C++ 生成的二进制文件里面, 这些重名的函数都是加了一些前后缀来进行避同的.

  而 C 是没有命名空间和函数重载的, 这个缺点换来了 ABI 兼容良好的优点.

  不过 C++ 提供链接规范(linkage specification)来为不同的语言声明链接协议,

  比如 C++ 模块可以为 C 模块提供避免名字改编的稳定符号, 从而实现 C 和 C++ 的模块相互调用的, 这就是 C/C++ 混合编程的真相.

  本人写了一个简单而完整的例子, 可以参考一下(点击下载).

  我们把 C++ 代码导出的 C API 叫做 C Wrapper API 或者 C bindings, 这个例子就是 C++ 为创建 C Wrapper API 的基本原理.

  实际中过程要考虑很多东西, 具体要考虑的事项参考这个 Mixing C and C++ Code in the Same Program,

  个人觉得这篇文章关于处理 C++ 的异常(exceptions)和类(classes)的部分说得不是太好, 所以我又额外提供了另外一个例子: Example of using C++ from C.

• 稳定的标准

  两者的语言标准都是有国际组织维护的. C++ 比 C 更新更加频繁, 语言特性逐年增加.

  这导致了 C++ 十分臃肿, 真要掌握起来学习成本极高.

  而 C 就没那么多特性, 概括起来就只有: 基本数据类型, 变量, 控制流语句, 函数, 指针, 宏.

  前面 4 个东西基本上只要是门编程语言都有的了, 而指针和宏则是大部分语言所没有的.

  早期在 IT 行业打下了基础, 现在也不需要大改标准, 因此它可以说是语法简单, 功能强大, 学了就终身受用.

  至于深受人们追捧的面向对象编程(OOP), C 语言确实不支持, 但实际上也是可以在 C 里面使用上的.

  实际上 OOP 原本不是什么高深的东西, 下面的内容是 OOP 提出者 Alan Kay 对 OOP 的定义:

  Source

  (I'm not against types, but I don't know of any type systems that

  aren't a complete pain, so I still like dynamic typing.)

  OOP to me means only messaging, local retention and protection and

  hiding of state-process, and extreme late-binding of all things. It

  can be done in Smalltalk and in LISP. There are possibly other

  systems in which this is possible, but I'm not aware of them.

  当然了, 现在很多语言的 OOP 比起最初的定义复杂太多了.

  而我们也不需要手动实现 OOP, 已经有人现成方案了(参考 Glib 的 GObject 子模块, 有兴趣的可以看一下这篇文章).

  如果要自己实现, 那么建议阅读一下 "21st Century C, 2nd Edition" 的第十一章.

• 为何人们喜欢把 if 相等判断的常量放在双等号前面?

  if (0 == res) {
    //  ...
   }
  

  这是因为 C/C++ 语言是可以在 if 语句里面对变量进行赋值的, 程序员可能会因为粗心写出如下代码:

  if (res = 0) {  // 原本想写 res == 0
    //  ...
   }
  

  而把常量放在前面则可以被编译器提示错误.

• 如何禁止编译器提示 "unused parameter" 警告?

  方法很多, 但有一个很奇怪的方法可以适用于任何编译器, 比如,

  void f(int x) {
    return;
    (void)x;
  }
  

  只要在函数里面使用 (void)param 这样就可以禁止这类警告了, 这个例子是在 return 之后使用,

  这个其实无所谓, 喜欢的话也可以放在 return 之前. 另外可以查看这个链接:

  https://stackoverflow.com/questions/3599160/how-can-i-suppress-unused-parameter-warnings-in-c

如果想学习 C 标准库的使用, 或者说 Linux 系统编程, 那么 The Linux Programming Interface 这本书就是必看的.

这本书的内容可以说是开发人员的必备基础之一, 同时也可以说是 C 语言练习册.

在 C 语言里面, 可以对数据进行隐式转换(implicit conversion). 比如:

int cloest_t = 3.14;

浮点数字面值(例如这里的 3.14)是双精度浮点数, 这个赋值会把双精度浮点数转换成整型, 也就是 cloest_t 的值是 3.

在一些数学计算中, 3 和 3.14 可能会让计算产生截然不同的结果, 这可能是开发人员的粗心导致的,

可以设置编译选现让编译器提醒潜在问题: GCC 的 -Wfloat-conversion.

该选项会提醒开发人员代码里面进行了 float 到 int 的隐式转换:

警告原文:

warning: conversion from ‘float’ to ‘int’ may change value [-Wfloat-conversio]

另外, 没有对宏的转换进行警告, 比如:

#define INF 3.14

int cloest_t = INF;

这点需要自己注意, 个人认为这可能是 BUG, 可能在之后的 GCC 版本里面被修正.

倘若真的想要进行转换, 那么可以使用显式转换:

int cloest_t = (int)3.14;

这样, 编译器就不会有警告了.

最后就是单精度浮点和双精度浮点之间的转换了.

这个是 GCC 手册里面的一个例子, 函数里面让双精度浮点和单精度浮点进行相乘.

float area(float radius) {
  return 3.14159 * radius * radius;
}

针对这个运算, 编译器会先让单精度浮点升格(promotion)为双精度浮点再进行运算, 最后把双精度浮点的结果降格(demotion)为单精度浮点进行返回.

在机器层面上, 双精度浮点数的计算需要更多的代价.

这段代码有两个解决方法:

1. 对 3.14159 进行单精度显式转换;
2. 对浮点数字面值加后缀: 3.14159f, f 表示单精度浮点数. (整型字面值也有其对应后缀, 有兴趣的可以看一下.) 推荐该方法.

针对这类问题, 可以使用 GCC 的 -Wdouble-promotion 选项来警告该类问题.

事实上, -Wfloat-conversion 也会对这个问题进行警告.

总的来说, 为了禁止双精度浮点/单精度浮点/整型之间的隐式转换, 我们应该使用 -Wdouble-promotion -Wfloat-conversion,

或者就单独使用 -Wfloat-conversion, 而这两个选项是 不会 在 -Wall 中被启用的.