Irrlicht and memory management

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
techiemac
Posts: 14
Joined: Tue Dec 26, 2006 7:16 pm

Irrlicht and memory management

Post by techiemac »

I had a suggestion for the improvement of Irrlicht and how it does memory management.

Currently I noticed that Irrlicht does a reference counting scheme (somewhat manual with grab() and drop()). I would like to propose moving to something somewhat like boost::shared_ptr<> (boost smart pointers found at http://www.boost.org ) in the case of shared heap objects. This would avoid passing flat pointers around and get rid of the potentially dangerous "delete this" paradigm.

Granted I understand, and respect the choice, to minimize external dependencies. At the very least, Irrlicht could leverage the boost::shared_ptr<> techniques to create something like irr::shared_ptr<> :)

The advantages of this are significant.

1. When using "delete this", the object is deleted but the pointer is not set to NULL. Therefore all subsequent NULL checks fail potentially causing access violations.

2. You can overload the assignment operator and copy constructor to handle all reference counting. Granted there are some pitfalls and perils to this but they are very well documented in the boost project.

3. If you do manage to dereference a pointer that has been deallocated, you can have the option to throw an safe exception instead of causing an access violation.

Of course with any advantage, there are pitfalls...

This would be a massive compatibility breaker for Irrlicht. All flat pointers would have to be wrapped in the shared_pointer causing many things to break. Yikes!

Believe it or not, it's not as bad as it seems. Though the smart use of typedefs, a little bit of time, and some rocking coding music, the refactor actually goes pretty quickly in my experience :)

Thoughts?

-Mac
JPulham
Posts: 320
Joined: Sat Nov 19, 2005 12:06 pm

Post by JPulham »

I've used smart pointers before, they can be useful and stop unwanted headaches sometimes :D
The IUnknown interface works well though...
pushpork
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Although it'snow called IReferenceCounted :D
techiemac
Posts: 14
Joined: Tue Dec 26, 2006 7:16 pm

Post by techiemac »

Of course I was just thinking of this to avoid the potentially dangerous "delete this" and the issue with all NULL pointer checks failing after. We all know how fun those access violations are to track down :)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

You won't make a library fool-proof with such a technique (or anything else) and you alread don't need delete in general anyway.
BTW: I guess that boost is not MSVC6 compatible...
Post Reply