Bug 52261

Subject: Re:  New: KSharedPtr not a perfect clone

On Dienstag, 24. Dezember 2002 21:13, you wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=52261
>            Summary: KSharedPtr not a perfect clone
>            Product: kdelibs
>            Version: unspecified
>           Platform: Compiled Sources
>         OS/Version: Linux
>             Status: NEW
>           Severity: wishlist
>           Priority: NOR
>          Component: general
>         AssignedTo: coolo@kde.org
>         ReportedBy: freak@codepimps.org
>
>
> Version:            (using KDE Devel)
> Installed from:    Compiled sources
> Compiler:          gcc 3.2
> OS:          Linux
>
> KSharedPtr doesn't have exactly the same semantics than a C++ pointer.  The
> template only works with instaces of the same type.  If U and T are related
> by a child parent relactionship than KSharedPtr<U> and KSharedPtr<T> should
> be compatible.  I have had to use direct KSharedPtr methods to get around
> these problems.
>
> Consider the following example:
> class A : public KShared {};
> class B : public A {};
>
> B *b = new B;
> A a = b;
> // but
> KSharedPtr<B> b = new B;
> KSahredPtr<A> a = b.data(); // Need to use KSharedPtr method, 2 different
> KSharedPtr can't work together here.

What do you suggest?

Greetings, Stephan

Subject: Re:  KSharedPtr not a perfect clone

On December 27, 2002 06:14 am, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=52261
>
>
>
>
> ------- Additional Comments From coolo@kde.org  2002-12-27 12:14 -------
> Subject: Re:  New: KSharedPtr not a perfect clone
>
> On Dienstag, 24. Dezember 2002 21:13, you wrote:
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> >
> > http://bugs.kde.org/show_bug.cgi?id=52261
> >            Summary: KSharedPtr not a perfect clone
> >            Product: kdelibs
> >            Version: unspecified
> >           Platform: Compiled Sources
> >         OS/Version: Linux
> >             Status: NEW
> >           Severity: wishlist
> >           Priority: NOR
> >          Component: general
> >         AssignedTo: coolo@kde.org
> >         ReportedBy: freak@codepimps.org
> >
> >
> > Version:            (using KDE Devel)
> > Installed from:    Compiled sources
> > Compiler:          gcc 3.2
> > OS:          Linux
> >
> > KSharedPtr doesn't have exactly the same semantics than a C++ pointer. 
> > The template only works with instaces of the same type.  If U and T are
> > related by a child parent relactionship than KSharedPtr<U> and
> > KSharedPtr<T> should be compatible.  I have had to use direct KSharedPtr
> > methods to get around these problems.
> >
> > Consider the following example:
> > class A : public KShared {};
> > class B : public A {};
> >
> > B *b = new B;
> > A a = b;
> > // but
> > KSharedPtr<B> b = new B;
> > KSahredPtr<A> a = b.data(); // Need to use KSharedPtr method, 2 different
> > KSharedPtr can't work together here.
>
> What do you suggest?
>
> Greetings, Stephan

I'm afraid every method in the template class needs to be a template.  For 
example, consider:  

KSharedPtr( const KSharedPtr& p )
    : ptr(p.ptr) { if ( ptr ) ptr->_KShared_ref(); }

I believe this should be transformed to something of the like of

template< class U >
KSharedPtr(const KSharedPtr<U>& p)
    : ptr(const_cast<U*>(p.data())) { if ( ptr ) ptr->_KShared_ref(); }

However, as stated, I believe every method must become a template to reach the 
stated goal: A perfect C++ pointer.  This single modification, at least, 
allows the given example to compile.

KSharedPtr<B> b = new B;
KSharedPtr<A> a = b; // Works fine now with updated method.

Finally, another alternative might be to replace with or add a smart pointer 
similar or identical to what is found in the boost libraries (www.boost.org).  
Boost constains a smart pointer template called shared_ptr<>.  It is really a 
wonderful thing to work with and a base class (KShared) is not required.

I have considered simply using the boost libraries from Krita, however, I felt 
obligated to try to the report my findings first.

This template code could be done like in std::auto_ptr<> . However, I just read a (quite recent) 
book about STL and it warns not to rely on this feature of auto_ptr, because most today's 
compilers can't handle member templates. In order words, I suggest scheduling addition of this 
feature to let's say year 2006. 
 
 

Subject: Re:  KSharedPtr not a perfect clone

On March 10, 2003 09:08 am, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=52261
>
>
>
>
> ------- Additional Comments From l.lunak@kde.org  2003-03-10 15:08 -------
> This template code could be done like in std::auto_ptr<> . However, I just
> read a (quite recent) book about STL and it warns not to rely on this
> feature of auto_ptr, because most today's compilers can't handle member
> templates. In order words, I suggest scheduling addition of this feature to
> let's say year 2006.

Auto_ptr doesn't offer very good semantics.  Look at boost::shared_ptr for a 
good smart pointer.  To see a good, un-shared, smart pointer have a look at 
boost::scoped_ptr.  Boost::scoped_ptr is truly what std::auto_ptr should have 
been.  Auto_ptr is sort of a mixed blessing, on it's own, it has failed.  
However, it sparked quite a few high quality implementations, in fact, you 
can fully expect boost::shared_ptr to be "promoted" to std::shared_ptr in the 
next round of standardization.

I have been using these smart pointers or similar home brewed types for the 
last 5 years without a problem.  Scott Meyer presented an auto_ptr 
implementation in 1996, this implementation was later republished in "More 
Effective C++".

I do not believe it makes sense to schedule such a feature for 2006 when it 
represents existing C++ practice today.  After all, boost runs tests on 
dozens of platforms with different compiler combinations.  

The KShared/KSharedPtr implementation in KDE seems more adequate for an 
internal string class implementation than a general purpose shared smart 
pointer.

At last, my plea for such a feature is simple:  If kdelibs does not offer such 
a base service, or heck even Qt, developers wanting it will simply import the 
boost ones into their projects or brew their own.

Now, I'm the first to admit that this isn't much of a plea, a quick survey of 
all of KDE reveals I'm a minority when it comes to actually using smart 
pointers.

I'm not going to code Shared pointer templates -> let Simon decide if he wants 
to go there. 

Subject: Re:  KSharedPtr not a perfect clone

On March 10, 2003 04:06 pm, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=52261
> coolo@kde.org changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- CC|                            |l.lunak@kde.org
>          AssignedTo|coolo@kde.org               |hausmann@kde.org
>            Platform|Compiled Sources            |unspecified
>
>
>
> ------- Additional Comments From coolo@kde.org  2003-03-10 22:06 -------
> I'm not going to code Shared pointer templates -> let Simon decide if he
> wants to go there.

If there is interest in including such a feature, I'm willing to code or 
modify such a pointer.

However, it would be nice to reach consensus on what a smart pointer in kde 
libs should look like.

I.e. if the specified pointer is a QObject, should special treatment be 
reserved for such a pointer?  Should the QObject::destroyed() signal be 
monitored?

Please re-confirm that the problem is still in KDE4, now that KSharedPtr points to the QSharedData class.

Nicolas Goutte wrote:
>
> ------- Additional Comments From nicolasg snafu de  2006-02-25 23:01 -------
> Please re-confirm that the problem is still in KDE4, now that KSharedPtr points to the QSharedData class.
>
>   



It is.

On the other hand, Krita doesn't use KSharedPtr anymore (especially since KSharedPtr became even more different from a normal C++ pointer). So unless other people are interested in this, well I think that this bug can be closed.

I think we can safely close this bug now.