问题描述

问题分析

初步分析

原因应该是分幅时，是先根据幅块大小，把hlz的文件建立出来了，如果某个幅块一个点都没有写，那么就只有一个头，是100M，修改方案为：如果一个幅块一个点都没有，那么删除这个hlz文件。

问题解决

由于对项目不熟悉，所以解决起来还是比较困难的

1. 锁定问题出现的位置：经过对代码逻辑的梳理，大致确定了是在文件删除时出了问题

2. 由于我不确定下面这行代码的作用，所以就先没有注释掉

   1	writers[sheet_index]->remove();

   通过增加

   1	std::remove(sheet[sheet_index].path.c_str());

   成功解决BUG！

   

   

然而，事情真的就这么简单的解决了吗？当然不是！

我兴奋地 commit 我修改的代码，然而收到的回复是：“你要弄懂为什么那段代码不起作用！”

问题深入

继续Debug，打断点，调试，我还和朋友开玩笑说，“今天的工作量，打了5个断点。”

通过我不断的F11，最终大致明白了它的删除逻辑，不得不说，对比起来，上学时写的代码真的是玩具啊。

这里的判断逻辑应该是有问题的，代码在 if(!creator)判断为 true，导致其直接返回，而没有进入return creator->remove();语句。

既然，代码没有进入remove()函数，那我就自己找找吧！我傻傻地点击右键“转到定义”，结果发现事情好像不太对，怎么在不断地调用类，这一刻我突然冒出一个念头，

“面向对象的设计固然好，理论上也增加了代码的可维护性，可是如我今天遇到的问题，本来直接执行一个文件删除语句就可以了，但是偏偏嵌套这么深，真的提高代码可维护性了吗？”

不过，千辛万苦之下，还是让我找到了，删除语句，可笑的是，

这和我写的不是一样的吗？？？

遗留问题

在单步调试的过程中，出现了这个错误，可是后来没有复现。

新的问题（0710）

Mt 说，还是梳理原有代码逻辑，所以我重新进行debug，考虑到数据集太大，运行一次都要半天的时间，所以考虑使用一个小的数据集来debug。

然而……，我发现代码中对于不同大小的数据集使用的处理逻辑是不同的，

• 对于小的数据集，在内存足够的情况下，读取点云一次，读出来存入内存，再使用多线程写入文件，这样做大大优化了处理速度
• 内存不够的话，是采取边读边写的逻辑

所以，我在debug的代码中，找到判断逻辑语句，把判断语句直接改成

1

if(false)

使代码强制走else语句，这个问题也让我加深了对占位符的理解。

好了，继续调试了。

啊啊啊啊啊啊！！！！！

最终，Mt 还是采取了我一开始的解决方案，因为发现在执行到remove之前，先执行了 close 操作，就已经把 creator 置空了，所以引发了后面的错误！

收工！