仅头文件形式的C库是否存在空间浪费？相关技术问题咨询

1. 为什么它不被编写为传统的.c和.h配对的形式？ #

jsmn是代码量仅数百行的微型JSON解析库，单头文件设计的核心出发点是最大化集成便利性：用户不需要额外添加库的编译单元到构建脚本，不需要预编译成静态/动态库，只需要把jsmn.h拖到项目目录，在需要用的代码里直接#include就能用，完全不需要调整构建配置，对于小项目、嵌入式场景的适配成本极低。

2. 链接器是否能够智能去重不同目标文件中完全相同的函数定义？我原本以为这种情况会出现「重复符号」错误。 #

首先默认不会出现重复符号错误，因为jsmn里的函数默认都加了static修饰，作用域仅限当前编译单元，每个目标文件里的函数副本对链接器都是不可见的，自然不会报符号冲突。
至于去重，主流编译器（GCC、Clang）的链接器提供了**相同代码折叠（ICF）**优化，只要编译时加-ffunction-sections参数，链接时加-Wl,--icf=all参数，就能自动合并完全相同的函数副本，不开这些优化的话不会自动去重，会存在空间浪费。

3. 在C语言（不包含C++）中，将代码放在头文件里有什么优势？ #

• 集成成本极低：不需要额外处理库的编译、链接逻辑，直接引入即可使用，适配不同交叉编译工具链也不需要额外调整
• 优化空间更大：函数定义完全暴露在当前编译单元，编译器可以直接做内联等优化，不需要依赖跨单元优化能力，对小函数的性能提升非常明显
• 分发简单：整个库只有一个文件，不需要做版本打包、库文件适配，直接复制头文件就能完成版本升级

4. 如果我在引入头文件前添加#define JSMN_HEADER语句，函数定义会从哪里获取？ #

定义JSMN_HEADER后，jsmn.h里被#ifndef JSMN_HEADER包裹的函数实现部分不会被展开，只会保留函数声明。
你需要单独创建一个.c文件，在该文件内不要定义JSMN_HEADER，或是显式定义JSMN_IMPLEMENTATION后再引入jsmn.h，这样这个单独的.c编译后就会包含所有jsmn的函数实现，其他文件链接时就会用这一份全局唯一的实现，不会产生冗余副本。

5. jsmn.h采用仅头文件的设计是不是值得学习的巧妙技巧？ #

这个设计是典型的场景向技巧，对代码量极小、功能单一的工具类微型库来说非常巧妙，把用户的使用门槛降到了最低，完全值得学习参考。
但不要不分场景滥用：如果你的库代码量较大（数千行以上）、依赖复杂，单头文件设计会大幅拉高编译耗时，修改库代码后所有引用它的编译单元都要全量重编，不开ICF优化时空间浪费也很明显，这种场景下还是传统的.c+.h分离设计更合理。

内容的提问来源于stack exchange，提问作者fadedbee