[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: New shared pointer - revision 2
From:       Frans Englich <frans.englich () telia ! com>
Date:       2005-09-11 12:51:12
Message-ID: 200509111251.12373.frans.englich () telia ! com
[Download RAW message or body]

On Saturday 10 September 2005 02:32, Frerich Raabe wrote:
> Hi,
>
> based on your feedback, I modificated the previously presented shared
> pointer a little:
>
> - All functions are documented now. In particular, get() got a warning
> which explains that the reference counting is circumvented, so you better
> be careful.
> - Inspired by a comment from Adriaan, I added a 'detach()' function which
> detaches a pointer. 'p.detach();' is simply nicer than 'p = p.copy();'
> - As requested by Thiago. Instead of an int, QAtomic is used as the type
> for the reference count. Pointer assignments are done via qAtomicSetPtr.
> This hopefully improves thread-safety.

Looks nice. In KXPath(XPath 2.0 implementation), branches/work/kdom/xpath, I 
use a modified copy of KHTML's SharedPtr, which have the following extension:

        template<typename X>
        SharedPtr(const SharedPtr<X> &o) : m_ptr(static_cast<T *>(o.get()))
        {
            if(m_ptr)
                m_ptr->ref();
        }

For example, this allows one to pass SharedPtr<B> to a function that takes 
SharedPtr<A>, if a static_cast from B* to A* succeeds. I'm no C++ expert, 
perhaps it can be done in a safer way(haven't tested it much neither). 
Boost's shared_ptr have this functionality, although it's implemented in a 
more elaborated way.

It would be great if scenarios covered by different SharedPtrs sprinkled all 
over the place could be covered by one or two central ones, of course.


Cheers,

		Frans
[prev in list] [next in list] [prev in thread] [next in thread]