多继承引发的诡异bug (cocos2d-x CCObject)
2014-11-15 16:32
459 查看
我有一个Singleton,用于处理下载信息,用到了HttpClient,那么就必须继承自CCObject,然后添加一个对应的函数指针来响应回调。由于同时还需要响应下载模块的信息回调,所以又继承自IDownloadEvent接口。
结果引发了一个非常难查的内存Bug。当回调函数调用后,这个Singleton的所有数据都被篡改了,导致函数内各种崩溃。但是我检查了Singleton的地址,又确实没有被改变,同时看了HttpRequest里面保存的target对象(就是我这个Singleton),它的数据又是正确的(地址跟我的Singleton一样,证明确实是一个对象)。
既然是同一个对象,地址又一样,为什么监视器中显示的变量数据完全不一样呢?
我猜想是由于多继承引发的问题。现在只保留一个对CCObject的继承,然后就解决了问题。
直到现在我还没有查明究竟是什么原因导致这个诡异的bug。但是可以明确多继承确实可能造成一些问题,是应该避免的。同时也说明使用继承的方式来完成监听者模式,在c++中不是一个很好的选择。即便继承的是只有纯虚函数的方法类,但是继承终究是继承,这个与java在语法层面实现接口的概念是不同的。
总结,尽量避免多继承,使用委托的方式完成信息回调而不是继承的方式。
结果引发了一个非常难查的内存Bug。当回调函数调用后,这个Singleton的所有数据都被篡改了,导致函数内各种崩溃。但是我检查了Singleton的地址,又确实没有被改变,同时看了HttpRequest里面保存的target对象(就是我这个Singleton),它的数据又是正确的(地址跟我的Singleton一样,证明确实是一个对象)。
既然是同一个对象,地址又一样,为什么监视器中显示的变量数据完全不一样呢?
我猜想是由于多继承引发的问题。现在只保留一个对CCObject的继承,然后就解决了问题。
直到现在我还没有查明究竟是什么原因导致这个诡异的bug。但是可以明确多继承确实可能造成一些问题,是应该避免的。同时也说明使用继承的方式来完成监听者模式,在c++中不是一个很好的选择。即便继承的是只有纯虚函数的方法类,但是继承终究是继承,这个与java在语法层面实现接口的概念是不同的。
总结,尽量避免多继承,使用委托的方式完成信息回调而不是继承的方式。
相关文章推荐
- 多继承引发的诡异bug (cocos2d-x CCObject)
- 一个Date对象引发的诡异bug
- (AS3)DisplayObjectContainer.contains + DisplayObjectContainer.removeChild 引发的狗血BUG
- 多继承下函数指针强制转换所引发的诡异问题(CCNotificationCenter)
- cocos2d-x中各种诡异BUG的一个原因
- 一个诡异BUG引发的血案(线程死锁造成的CPU利用率逐渐增高)
- [原]fopen打开文件方式错误引发的bug
- Object-C之Bug集中营
- 由JavaScript中call()方法引发的对面向对象继承机制call的思考
- object 属性 对象的继承 (原型, call,apply)
- 深入jdk——追踪Collections.sort 引发的bug(2)TimSort思路
- 由创建一个不能被继承的类引发的对象模型的思考
- JDK1.6集合框架bug:c.toArray might (incorrectly) not return Object[] (see 6260652)
- Class.create和 Object.extend继承操作
- 多线程+fork 引发的bug查找
- JS原型链 new 与 Object.Create()区别 代码及继承的方法
- Xamarin.Forms框架引发APP崩溃典型bug
- C++多重继承引发的重复调用问题与解决方法
- [Object]继承(经典版)(四)多重继承和组合继承
- 诡异的Android开发中EditText键盘弹出后被遮盖的bug