1.c++protected继承和private继承是源码不是没用的废物?
2.数据结构专题(三) | iVox (Faster-Lio): 智行者高博团队开源的增量式稀疏体素结构 & 源码解析

c++protected继承和private继承是不是没用的废物?

       既然你所统计的项目里出现了 private 继承和 protected 继承，这不正说明确实有他们的源码用武之地吗？

       让我们来康康 C++ 代码的标杆——STL 的源码，是源码怎么做的：

       先来康 GCC 自带的 libstdc++ 的实现：

       vector, list, deque, forward_list, unordered_(multi)set/map 的底层都有用到 protected 或 private 继承。

       比如 vector 会空基类压缩优化技术，源码这只能用继承实现，源码而使用组合时就没有压缩的源码淼迈源码效果。

       考察下面代码，源码这是源码对 vector 压缩 allocator 字段原理的简化实现：

       如果 vector 直接 public 继承自 allocator，根据类型兼容原则，源码在指针和引用语义下，源码子类同时也可被视作是源码父类。那 vector 也能被当做 allocator 用了？这会引发语义混乱。源码淘宝人生源码

       而改成 private 或 protected 继承就不会了：

       这时候编译器会报错，源码这阻止了上面的源码情况发生。这样的源码例子比比皆是。

       还有 tuple 对空类字段的压缩，也采用了这个手法。

       2）既然谈到了 tuple，我们就来考察一下 tuple。

       这次我不亲手写代码了，就百度一下，随手找找一篇博客现场打脸好啦。

       百度搜“std::tuple 实现”，软著源码模板第一篇博客用常规思路来实现 tuple，即：取到第一个模板参数后，作为一个数据成员，然后递归继承 tuple。这份实现没有用到空类成员压缩优化，不过没关系，反正这个优化也不是强制的。

       但是，如果使用 public 继承，类型兼容原则会导致 tuple 是 tuple 的子类，那么就可以当父类去用。矿机搭建源码这将引发大坑，比如接收二元组参数的函数接收到的居然是一个三元组。这种低质量的库在业务代码里是不可用的。

       总结一下，protected private 继承能暴露问题，避免不当使用时的隐患；空基类优化的需求使得必须用继承实现，而 public 继承会产生奇怪的语义，这决定了 protected private 继承在模板库中很有用。

       业务代码在使用继承时，往往只是为了利用多态性，而模板库在设计时会考虑到所有场景，返利原生app源码所以 protected private 继承在模板库中用得多，在业务代码中用得少。

       最后，private protected 继承虽然在实践中用得相对较少，但他们绝不是像 vector, auto_ptr 这样的实在是非常拉垮的设计。他们在模板编程中十分有用！

数据结构专题(三) | iVox (Faster-Lio): 智行者高博团队开源的增量式稀疏体素结构 & 源码解析

       在年初，智行者高博团队和清华大学联合发表了Faster-Lio的工作，该成果收录于IEEE RA-Letters，其开源代码展示了如何通过增量式稀疏体素结构iVox，提升Lidar-inertial Odometry（LIO）的算法效率。相较于MaRS-Lab的FastLio2，Faster-Lio在保持精度的同时，得益于iVox的设计，尤其是在增删操作上的高效性，显著减少了维护local map和查询近邻的时间。

       高博在知乎文章中详细解读了Faster-Lio，特别是iVox的创新设计。我们从数据结构的角度出发，通过简化的方式解释iVox：首先，利用哈希表（如C++的std::unordered_map）将体素空间坐标作为key，通过精心设计的空间哈希函数映射到有限的索引空间，实现快速的增删操作。哈希表的优化和抗冲突设计使得碰撞概率极低，即使有冲突，也能快速忽略。

       此外，iVox采用了伪希尔伯特曲线（PHC）来组织体素，这种曲线将高维空间划分为一系列单元，并通过分段曲线连接，便于一维空间索引。尽管希尔伯特曲线是理想化的，但在工程实践中，PHC在接近填充空间的同时，保持了可接受的实现复杂度。

       Faster-Lio的源码解析显示，核心在于IVox类，其中grids_map_和grids_cache_是关键数据结构。AddPoints()负责增量点的添加，通过哈希查找确保高效，而GetClosestPoint()则通过kNN搜索找到最近邻。

       尽管论文与代码存在一些差异，如体素过时删除策略，但整体上，iVox的设计思路清晰，哈希表和空间组织策略的结合使得其在实际应用中表现出色。然而，对于体素内点的处理，实际工程中可能更倾向于简化，例如通过体素降采样和八叉树结构，这些方法在某些场景下可能会比PHC更易于实现。

       最后，作者WGH无疆强调，iVox是简单实用的解决方案，但希尔伯特曲线在工程实践中的优势可能有限，尤其是在点数不多的情况下。未来，他们将探讨其他类似的工作，如CMU的Super Odometry，其中可能结合了哈希表和八叉树。欢迎大家继续关注和交流。