raabe at kde.org
Sun Oct 23 16:39:18 BST 2005
On Sunday 23 October 2005 05:52, Hamish Rodda wrote:
> This practice is commonplace throughout at least KSycocaEntry.
For the record, stuff like this is not all that un-common in KSycoca either
KSycocaEntry::Ptr servType = (*m_entryDict)[ _name ];
return (KServiceType *) ((KSycocaEntry*)servType.get());
Looks to me as if somebody couldn't really decide whether to use shared
pointers or not, and ended up happily converting back and forth between dumb
and shared pointers.
> 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, and you can't assign from
> KSharedPtr of different class types either (only via the dumb pointer
> method above, hence it's no good). So, KSycocaFactory::create() won't
> compile in subclasses. I can't think of a great solution here.
I added a template constructor and a template assignment operator to
KSharedPtr. I'm currently rebuilding kdelibs which takes ages on this laptop,
but I'm already past kdecore (which means, past ksycoca.cpp and past
kprotocolinfo_), so I'm positive. I hope I don't forget to attach a patch to
this mail which shows these changes.
I also added an 'isUnique' function which returns whether a given KSharedPtr
is the only one referencing the pointee (I saw that Stephan had to tweak
addressee.src.cpp a bit, and this function is meant to be used there) but
left it in.
> For now, i'm planning to comment out the delete line in KSharedPtr (i know,
> not good) and keep working on kate ;) but if anyone is interested in how
> far i got, my patch is at
I'm currently rebuilding kdelibs with that page.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2641 bytes
Desc: not available
More information about the kde-core-devel