about kde4's smart pointer

Frank Osterfeld frank.osterfeld at gmx.de
Tue Oct 3 22:09:17 BST 2006


On Wednesday 04 October 2006 00:24, Frans Englich wrote:
> On Tuesday 03 October 2006 22:16, Frank Osterfeld wrote:
> > On Tuesday 03 October 2006 17:10, Thiago Macieira wrote:
> > > Cyrille Berger wrote:
> > > >On Tuesday 03 October 2006 16:08, Thiago Macieira wrote:
> > > >> Doesn't QSharedData/QSharedDataPointer do what you want? They have
> > > >> copy-on-write semantics, though.
> > > >
> > > >yes and that's the problem :) They are designed to reduce the number
> > > > of copy, not to replace pointers and be used as smart pointers.
> > >
> > > There's QPointer, but your object has to be a QObject.
> >
> > QPointer only guards the pointer (i.e. resets it to 0 if deleted), but it
> > doesn't do refcounting and auto-deletion. In my own code, I use Frerich's
> > KSharedPtr replacement he proposed here a year ago [1]. One of it's
> > advantages is that it's not necessary for the the shared type to inherit
> > KShared, so one can use the type as normal non-pointer object (IIRC
> > operator=() etc. is private for KShared).
>
> Why would you want to store a reference counted object on the stack? As an
> optimization?

I had a case where in 90% of the code I didn't want to use pointers for the  
class instances (neither shared nor non-shared ones), but needed (shared) 
pointers in a few places (due to polymorphism IIRC). I think a shared pointer 
class should work with arbitrary classes and not force them to inherit 
KShared or prevent operator=() etc. from working.

Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061003/cd713bbf/attachment.sig>


More information about the kde-core-devel mailing list