raabe at kde.org
Sun Oct 23 19:28:58 BST 2005
On Sunday 23 October 2005 14:43, David Faure wrote:
> On Sunday 23 October 2005 18:05, Frerich Raabe wrote:
> > On Sunday 23 October 2005 15:39, Frerich Raabe wrote:
> > > On Sunday 23 October 2005 05:52, Hamish Rodda wrote:
> > > > I tried to
> > > > port it over to 100% shared pointers, but encountered a problem with
> > > > covariant returns - KSharedPtr can't be used (in its current form) in
> > > > a covariant return with different class types
> > This is a bit tricky, but looking at what KSycoca* is doing, maybe
> > there's an easy way out. Take KSycocaFactory::findServiceByName:
> > virtual KServiceType * findServiceTypeByName(const QString &_name);
> > It returns a raw pointer, not a shared one, but doesn't document who's
> > supposed to call delete on the pointee. If we're lucky, the caller is
> > supposed to do so
> Not at all, this pointer is only a cast of a KSharedPtr, i.e. a pointer
> that kdelibs will delete all by itself.
> The caller is NOT supposed to delete a KServiceType, ever.
> A better API for this method would be to return a KServiceType::Ptr, I
How about making KSycocaEntry (and all the stuff that inherits it -
KServiceType, KProtocolInfo et cetera) classes with value semantics, making
it do all the reference counting internally. So you'd have a 'KServiceType
KSycocaFactory::findServiceByName( const QString & )' function and so on.
Besides the nice side-effect that value semantics don't even trigger the whole
'Who owns this thing?' thing, it would solve the problem with covariant
return types which you get when returning a SharedPtr<Foo> instead of a Foo*.
Instead of giving a long explanation, I just attached a tiny testcase which
demonstrates the problem. It works if you define WORKS, it doesn't if you
P.S.: I love this KMail feature which reminds you to attach something. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 531 bytes
Desc: not available
More information about the kde-core-devel