New shared pointer

[Koos Vriezen]

On Saturday 10 September 2005 Frerich Raabe wrote:

> the current shared pointer implementation in KShared/KSharedPtr is a little 
> too simplistic IMHO:
> 
> - it requires all classes with onto whose objects you want to point with a 
> KSharedPtr to provide the interface given by KShared; in practice, this means 
> that you might have to change the code of the target class because you either 
> need to make it inherit KShared, or you add the ref()/deref() functions

[..]

> P.S.: I considered using QSharedData/QSharedDataPointer but that duo has 
> exactly the same two problems as KShared/KSharedPtr I mentioned above. I also 
> considered boost::shared_ptr but noticed that it pulls in a lot of other 
> funky template magic (which, as the honest tears of a certain SUSE engineer 
> agree with, might be a little too much for the compiler of choice).

FWIW, and probably too late, there are at leat two 'light' version of
the boost onces. There is one in the remote desktop code and mine in
KMPlayer, which is even lighter. It would have been nice if you would
have taken one of these, as they are already well tested and it's a bit
of a waste to write yet another one, no?
One thing you are missing is the addition of boost's weak_ptr, which I
use alot. Same reason you mention above for having to inherit KShared
for having shared pointers is having to inherit QObject for QGuardedPtr.
So with weak_ptr one has both.

To give an example where WeakPtr has a huge benefit in KMPlayer.
KMPlayer has a w3c like DOM tree based on shared_ptr/weak_ptr. If a
certain node wants to create child nodes, and pass itself as parent, it
can't just send 'this' because 'this' is also in a SharedPtr of its
parent. So what I did was that all nodes have a WeakPtr of itself as
protected member.
This is the disadvantige of SharedPtr, a certain object has no 'this'
anymore that it can pass arround.

Koos