内存释放的问题

vruser

在不用代码 osg::ref_ptr<osg::Geode> geode = new osg::Geode();
而使用代码 osg::Geode *geode = new osg::Geode();  的情况下，

如何释放这个指针呢？

OSG论坛管理员

不要使用 osg::Geode *geode = new osg::Geode();
关于OSG内存管理的理论，可以参考帖子附件：http://bbs.osgchina.org/viewthread.php?tid=298&extra=page%3D1

关于超级指针一节。
有官方明确评论，使用osg::Geode *geode = new osg::Geode();
等等是极不安全的，当时用了个very的叹词，事实上，代码一大，用类似代码多会产生内存什么问题而无故崩盘

OSG论坛管理员

在array所译入门指南中也对超级指针有述

vruser

在osg自带的例子中，还出现过 osg::Geode *geode = new osg::Geode();  的写法

OSG论坛管理员

那是单个文件，函数很少，而且没有交互，Geode一直出现，如果场景复杂，有交互，有些时候一些Node需要隐藏，删除或是重新载入，那样用就不安全了

OSG论坛管理员

在《基本渲染理论中》有三种方法：

1. 19 // This is OK, albeit a little verbose.
   
2. 20 osg::ref_ptr<osg::Geode> aGeode (new osg::Geode());
   
3. 21 MayThrow();
   
4. 22 group->addChild (aGeode.get());
   
5. 23
   
6. 24 // This is quite safe, too.
   
7. 25 group->addChild (new osg::Geode());
   
8. 26
   
9. 27 // This is dangerous! Don’t do this!
   
10. 28 osg::Geode* anotherGeode = new osg::Geode();

复制代码

有下面的描述：

关于上面示例，我们值得注意的是一件事情：我们1.3节所示的关于如何组织场景图形成了初步的认识。（现在，为了满足大家的好奇心，下一节我们将更进一步来谈论大家都感兴趣的事情）。该示例给出了安全使用OSG超级指针的两个方法以及避免使用一种危险的方法来使用它们：
&#61656; 第20行到22行，示例了一个比较安全的方式来使用超级指针，一个osg::ref_prt<>（叫做aGeode）在第20行被初始化为osg::Geode(资源)。在这一点上，关于geode的引用计数器在堆内会被置1（因为osg::ref_ptr<>中只分配了一个Geode,故可以命令为aGeode）。
在稍后的第22行，geode被当做一个孩子加入到一个组当中。这个操作一旦执行结束，组对geode的引用计数就会增加1，变为2。 现在，有哪些比较烂的事情发生了呢？如果我们在第21行调用MayThrow()之后，会发生干什么事情呢？好的，aGeode将会超出范围，然后被析构掉。然而，在它的计数减至0之后，它仍会合适的处理该geode,这时也没有内存泄漏。
&#61656; 第25行或多或少的与前面几行做了相同的事情，不同的是geode被一个简单的new语句分配以及只用了一小行便添加到组当中。这是相当安全的，因为在彼此之间发生了如此多的坏事情（毕业，这里也没有彼此）。
&#61656; 坏的、错误的、危险的以及应该被责备的方式来管理内存是从第28到第30行的做法。它看起来和第一种是一样的，但是geode是被new分配的且存储在一个普通的指针当中。如果MayThrow()在第29行被抛出，没有人会调用Delete,这时geode就发生了泄漏。
这里有另外一件事情颇值得一提：osg::Referenced的构造函数有时候并不都是公有的，所以你有可能不能说直接的删除anotherGeode，因为该类是从osg::Referenced派生而来。从osg::Referenced派生而来的类实例(像osg::Geode)采用osg::ref_ptr<>进行管理只是简单的意味着该类会自动的管理它的内存空间。 所以，做正确的事情，永远不要使用第三种方法来写代码。