遍历删除

本文主要是介绍遍历删除，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

今天想实现个小功能：战斗结束时，后台先立即退房间

• 退房间逻辑包含了：所有人退光后，销毁房间
• 销毁房间，会同步销毁GameWorld

在OnPlayerDie回调中加了一句代码，导致连续出现四处宕机bug~太牛逼了

• Bug分属四处不同模块
• 均是同种原因：遍历中途，删元素，上层持有的引用失效

很好修复，但这不是重点。重点是，这bug同时隐匿在

• 系统最底层，碰撞检查器，遍历调用OnTriggerEnter
• OnTriggerEnter 参数中的某些对象已被销毁
• 系统底层，GameWorld update
• 系统底层，GameWorld内置计时器
• GameWorld都没了，还在跑遍历
• 业务层，OnPlayerDie遍历队伍，通知调用链中，触发退队，迭代器失效

分别不同人写的模块，且不做本次业务改动，跑得很稳定

• 也就是说：在写模块时，开发者都没想到这bug。这里有两层缘故：
• 一是，迭代遍历，太常见，太顺手了 …… 依赖个人警惕，非常不靠谱
• 交叉review靠谱点，但现实里review是需要成本的，极少团队愿意支付这个成本
• 二是，上述模块均带回调事件
• 回调链，究竟多长，会做啥 …… 不受起初写该模块人的控制
• 是个需求上就非内聚的东西

  本质是：持有着某对象的引用，调用事件函数后，共享出去了它的操作权，但写的人忘了它会被改，更不能期望别人会主动通知。   根本解决方案：支持一套迭代安全的容器模板，仅高内聚的模块允许使用原生迭代器

• 预想的坑：回调链中，可能再次调用到遍历（函数重入），常规类中记个游标的方式，也是不安全的

  【扩展联想】

• 析构比构造难多了
• c艹的确定性析构，需要开发者准确掌握资源回收的时序
• 业务层的资源回收步骤，往往带着很长的调用链
• 写这个，有种网上描述屎山代码的体验~改个小地方，崩一片
• 如若是线上版本开发，做这个的程序，会是啥心态
• 作为管理者，你会悉心了解问题本质，企图改掉它们吗？大概率不会
• 完整解决它的可能性极低，大约会搞成延时删除、拷贝遍历之类的
• 不解决根本问题，下一个不注意的仍会踩坑 …… 避开坑，而不是填坑
• c++是个很棒的语言，但得重新审视下它做业务开发的性价比
• 其它语言碰见这bug的印象淡许多
• c# foreach 遍历删会报容器被修改的异常
• go for range 删不会报错
• 带gc的语言，这方面表现好得多。但一样有坑点
• 比如遍历中途加元素，引发扩容
• 你还在遍历的，仍是老的内存块，老的元素

这篇关于遍历删除的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！