如何构建无需逐函数添加inline声明的header-only库？

你首先有个认知偏差：Boost、CGAL这类header-only库并不是没有处理ODR（单一定义规则）冲突，只是它们用的机制不需要给每个函数手动写inline关键字而已，核心逻辑分几类：

• 占代码量绝大多数的模板相关代码，天生不受ODR跨翻译单元重定义的限制
  C标准明确规定，函数模板、类模板的成员函数、模板的显式特化/偏特化，只要所有翻译单元中的定义完全一致，就可以在多个编译单元中同时存在，不会触发链接重定义错误。这类代码本来就不需要加inline，也是所有header-only库占比最高的部分——你自己写的示例里的模板函数templFunc，就算去掉inline关键字，放在头文件里被多个cpp包含也不会报错。
  除此之外，在类/结构体定义内部直接实现的成员函数（哪怕是非模板的普通成员函数）、C11之后的constexpr/consteval函数，默认都自带inline属性，同样不需要手动额外写inline关键字。
• 剩下的非模板普通函数，都用了其他规避ODR的手段，不是没做处理
  你翻这类库的源码会发现，少量非模板的工具函数基本都用了下面几种写法：
  • 放在匿名命名空间namespace { /* 函数实现 */ }里：匿名命名空间里的符号是内部链接属性，每个包含头文件的编译单元都会生成自己的私有副本，互相完全不可见，根本不会产生链接冲突。
  • 用库自定义的inline宏包裹：很多库会封装类似LIB_INLINE、FORCE_INLINE的宏，根据编译环境展开成对应平台的inline/forceinline修饰符，不是没加inline，只是被宏替换了，你扫代码的时候没第一眼看到裸写的inline而已。
  • 声明为static修饰的自由函数：和匿名命名空间效果类似，符号为内部链接，每个编译单元持有独立副本，不会冲突。
• 关于你提到的代码组织方式的额外说明
  你觉得「普通函数声明放.h、实现放.cpp，模板实现放.h」是不良实践、结构混乱，本质只是个人习惯问题，这种写法恰恰是C++项目发展几十年验证下来的标准工程实践，最大的好处是能大幅减少编译时间——如果把所有实现都塞在头文件里，只要你改了一行函数逻辑，所有包含这个头文件的cpp都要全量重编，项目规模上来之后编译耗时会涨到完全无法接受的程度。接口与实现分离带来的可维护性、编译效率收益，远高于“所有代码放在同一个文件”的整洁感。
  如果你确实想写纯头文件的模块，也不用硬给所有函数加inline：模板、类内成员、constexpr/consteval函数直接写就行，普通自由函数要么放匿名命名空间，要么补个inline修饰，就不会出链接错误。

内容的提问来源于stack exchange，提问作者Maxime Charrière