Dear all,
Herewith I’d like to summarize some suggestion and short discussions we had in the last few weeks regarding the use of smart pointers for improving the memory management in Calitko. I hope we could come with the practices that should be used in Calitko in each of the different use cases. I hope at least some of you would take part in the discussion.
First, the background! Some weeks ago Atul suggested that we use boost’s smart pointers instead of normal pointers. After that Anders Larsen digged out the class QSharedData, from which one can simply derive in order to get implicit sharing through reference counting. Just yesterday Anders Karlsson suggested that auto_ptr, which is a very simple kind of smart pointer, is used in place of plain pointers.
My suggestion is that a section about memory management is added to Calitko Coding Conventions. All new code must be conforming to the coding conventions in order to be committed in mainstream. Below is an initial draft. Please post your comments and suggestions for improvements. With ‘??’ I’ve marked places where I thought more could be said but didn’t know exactly what. Hopefully you’ll have suggestions.
======================
Calitko Coding Conventions
Memory Management
This section recommends some practices, which would reduce the risks of and simplify issues related to managing dynamically allocated memory. Clearly, the best way to avoid such problems is not to do it! This means that whenever possible one should prefer declaring objects on that stack instead of on the heap. If you do so, then the compiler takes care of destroying the objects and freeing the associated memory.
Implicitly shared private data
It is recommended that custom types implement implicit sharing by means of reference pointers. Doing so would reduce the const of copying and assigning objects of custom types. These operations would be needed more often as values instead of pointers are copied to and from the stack. Qt4 provides the class QSharedData, which can be used together with QSharedDataPointer to implement reference counting on private data.
Passing objects to functions
Arguments of generic types should be passed by value, unless they are designed to be used as output arguments. Arguments of user defined types should be passed by constant reference, unless designed to be used as output arguments, in which case non-const reference should be used. Avoid passing pointers to objects. ??Except for which cases?? Not passing pointers to objects saves some thinking about who is the owner of the object.
Returning values from functions
Objects of non polymorphic types should be returned by value. The cost of copying the object will be small if implicit sharing is used. For functions that return objects of polymorphic types through pointer to the base class should return and auto_ptr for the base class instead. Using auto_ptr automatically passes ownership of the heap-allocated object to the caller. If the auto_ptr goes out of scope and it still owns the object, the object will be deleted. If the caller fails to assign the return value, the object will be deleted as the temporary auto_ptr gets destroyed.
Member and non member pointer variables
An auto_ptr should be used instead of a plain C pointer. Using auto_ptr guarantees that the object will be deleted as the auto_ptr goes out of scope and increases exception safety.
Objects as arguments in signals and slots
Object of non polymorphic types should be passed by value. Copying will be efficient if reference counting of the private data is used. Objects of polymorphic types that are referenced with (non) const references/pointers to the base class should be emitted in signals only using smart pointers (?? maybe boost ??). In this case auto_ptr is not suitable since there may exist multiple slots connected to the same signal. That would result in copying the auto_ptr multiple times and maximum one of the slots will get an auto_ptr that still owns the object.
======================
Do you think that something more could be added? Corrections?
Regards,
Peter
