Warning, /multimedia/amarok/HACKING/smart_pointers.txt is written in an unsupported language. File is not indexed.
0001 QWeakPointer 0002 ==================== 0003 QWeakPointer is a guarded pointer for QObjects, so it automatically becomes 0 when 0004 the data it points to is deleted. If you have a member variable that's a QObject 0005 and are ever worried that it might be dangling, make it a QWeakPointer. There's 0006 really no reason not to for variables that stick around, it adds little 0007 overhead. 0008 0009 KSharedPtr 0010 ==================== 0011 Unlike QWeakPointer, KSharedPtr is dangerous and must be used carefully. 0012 0013 == Undercounting == 0014 KSharedPtr uses reference counting. When a KSharedPtr is in scope, it adds one 0015 to the reference counter. When a KSharedPtr loses scope, it deletes one from the 0016 reference count. When the reference count become 0 it deletes the object. So if 0017 there were any normal pointers to that data and all the KSharedPtrs are deleted, 0018 then the object is deleted and the normal pointers dangle. Segfaults ensue. 0019 0020 The solution is to just make sure that any normal pointers are temporary and 0021 everything else is a KSharedPtr if reference counting is required for your class. Even 0022 if the pointer is temporary, but is then handed off to some other class that 0023 might keep it around, that's a potentional crash now or in the future. 0024 0025 0026 == Reference Cycles == 0027 One issue with reference counting in general is the creation of a reference 0028 cycle. If class A has a KSharedPtr<B> property and class B has a KSharedPtr<A> 0029 property and two objects of A and B point to each other and the KSharedPtrs 0030 loose scope, a reference cycle is created. Despite not being accessible from 0031 anywhere in the program, the reference counter of KSharedPtr<A> and 0032 KSharedPtr<B> will never go to 0. Memory leaks. The solution is to be careful. 0033 0034 == Dreaded Diamonds == 0035 Since the objects KSharedPtr point to must derive from QSharedData, it's not 0036 uncommon for a "dreaded diamond" inheritance issue to arise. Basically if A and 0037 B both inherit QSharedData and C inherits A and B, then C inherits QSharedData 0038 twice. The solution is really easy, just add a 'virtual' keyword when A and B 0039 inherit QSharedData. Eg class A : public virtual QSharedData. Details at: 0040 http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8