Home · Modules · All Classes · All Namespaces
Shared Pointer Usage

Overview

The Qt parent/child object model does not fit well with Telepathy-Qt object model, where in some places we either don't know the object parent or we can't use a parent, as the object can stay alive without it.

To avoid memory leaks, caused by objects that got instantiated and don't have any parent, we decided to make some of our objects reference counted, by making them inherit RefCounted.

Making the object reference counted, does not guarantee that it will get deleted when nobody is referencing it.

When instantiating new classes that inherits RefCounted the reference count is 0, this is referred to as the floating state. Again this may lead to memory leaks, caused by objects in the floating state that never get deleted.

So the solution is to put the object in a SharedPtr as soon as possible, letting the SharedPtr manage the object lifetime.

The pattern used is that classes inherit RefCounted and are used together with SharedPtr. When the reference count hits 0, the object is deleted.

In order to assure that the object is put in a SharedPtr as soon as possible, our objects inheriting RefCounted will have the constructor either private or protected, in case we want to support custom classes, and will have a public static create method that will return a SharedPtr pointing to the object instance.

Note that when developing custom classes, this pattern should be followed, to avoid objects in floating state, avoiding memory leaks.