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.
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.