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 实现”,pom文件引入源码第一篇博客用常规思路来实现 tuple,即:取到第一个模板参数后,作为一个数据成员,然后递归继承 tuple。这份实现没有用到空类成员压缩优化,不过没关系,反正这个优化也不是强制的。
但是,如果使用 public 继承,类型兼容原则会导致 tuple 是 tuple 的子类,那么就可以当父类去用。论坛功能源码这将引发大坑,比如接收二元组参数的函数接收到的居然是一个三元组。这种低质量的库在业务代码里是不可用的。
总结一下,protected private 继承能暴露问题,避免不当使用时的隐患;空基类优化的需求使得必须用继承实现,而 public 继承会产生奇怪的语义,这决定了 protected private 继承在模板库中很有用。
业务代码在使用继承时,往往只是为了利用多态性,而模板库在设计时会考虑到所有场景,办办源码博客所以 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,其中可能结合了哈希表和八叉树。欢迎大家继续关注和交流。