CGAL头文件引入规则及所需头文件查询方法相关咨询

给出示例代码：

#include <iostream>
int main() {
  std::cout << CGAL::square(0.002) << '\n';
  return 0;
}

已知CGAL::square函数定义于Algebraic_foundations/include/CGAL/number_utils.h，以下是相关问题的解答：

问题1：仅引入<CGAL/number_utils.h>无法完成编译，需额外引入<CGAL/basic.h>或更细粒度的<CGAL/number_type_basic.h>才可正常编译，请问该现象的原因是什么？ #

CGAL的头文件遵循分层依赖设计规则，功能头文件不会主动引入依赖的底层基础定义。CGAL::square虽然逻辑上定义在number_utils.h中，但其实现依赖的CGAL全局基础宏、泛型参数约束、数值类型断言等基础定义，都存放在CGAL/number_type_basic.h中；而CGAL/basic.h是CGAL全库的基础入口头，本身已经包含了number_type_basic.h以及其他全局配置、通用类型定义。number_utils.h本身没有自带这些基础依赖的引入，因此单独引入会因为缺少基础定义触发编译报错。

问题2：使用细粒度头文件引入是否会减少编译单元文本量从而降低编译时间？编译器是否会清除未使用引入的冗余代码，使得最终生成的可执行文件、目标文件无差异？ #

• 细粒度头文件确实会降低编译耗时：引入的头文件越少，单个编译单元预处理后的文本量越小，预处理、语法分析、语义检查阶段的工作量就越少，全量编译速度提升会非常明显，项目引用的CGAL模块越多效果越突出。
• 现代C++编译器（GCC、Clang、MSVC）默认都会开启多层未使用代码消除逻辑：编译阶段会过滤头文件中未被引用的模板、函数、常量定义，不会生成对应目标代码；链接阶段还会执行死代码删除做二次校验。只要最终引用到的CGAL功能完全一致，不管用细粒度头文件还是高层头文件，最终生成的目标文件、可执行文件内容没有差异。

问题3：使用细粒度头文件引入是否有其他依据，比如风格规范要求？反之引入高层头文件避免底层代码变动影响是否属于最佳实践？ #

CGAL官方开发规范明确推荐用户优先引入对应功能的最细粒度头文件：一是可以明确代码依赖的CGAL能力范围，二是避免引入不必要的依赖拖慢编译速度。
引入高层头文件虽然能省去查找头文件的成本，也能规避底层头文件路径、名称变动的影响，但不属于CGAL使用场景下的最佳实践：CGAL稳定版本中对外暴露的中低层头文件路径、名称都是固定的，不会轻易变动；反而高层头文件会引入大量无关依赖，大幅拉低编译速度，对于需要频繁编译的开发场景得不偿失。

问题4：CGAL提供了哪些高层头文件？是否存在覆盖整个库的统一高层头文件？各功能包之间的头文件关联逻辑是什么？是否每个功能包都对应独立的高层头文件？ #

• CGAL没有覆盖整个库的统一高层头文件，因为CGAL是高度模块化的大型计算几何库，全量引入所有头文件会带来极大的编译负担，官方也不推荐这种用法。
• 每个独立功能包（如代数基础、几何内核、凸包计算、2D三角剖分等）都有对应的独立高层头文件，命名规则为<CGAL/[包名].h>，例如代数基础包的高层头是<CGAL/Algebraic_foundations.h>，2D三角剖分包的高层头是<CGAL/Triangulation_2.h>。
• 功能包之间的头文件关联逻辑如下：高层头文件会自动引入当前包所有公开功能对应的头文件，以及当前包依赖的其他功能包的基础头文件；同功能包内的低层头文件只会引入自身实现直接依赖的其他头文件，不会引入同包的其他无关功能头文件。

问题5：若引入中低层头文件属于推荐实践，那么查询所需头文件的标准工作流是什么，例如上文示例中CGAL::square函数对应的头文件如何定位？ #

标准查询流程如下：

1. 先确定用到的API所属的功能包，例如CGAL::square属于代数基础（Algebraic Foundations）包的数值工具类API；
2. 查阅对应功能包的API参考文档，每个API的说明条目顶部都会明确标注该API需要引入的头文件名称，以及需要额外引入的依赖头文件；
3. 没有文档的情况下，可以直接在CGAL头文件目录下用文本搜索工具搜索API名称，匹配到的头文件顶部说明区域都会标注该头文件的依赖引入要求，按照要求引入即可。

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