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

List:       kde-core-devel
Subject:    Re: about kde4's smart pointer
From:       Frank Osterfeld <frank.osterfeld () gmx ! de>
Date:       2006-10-03 21:09:17
Message-ID: 200610032309.18362.frank.osterfeld () gmx ! de
[Download RAW message or body]


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

[Attachment #3 (application/pgp-signature)]

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