KSharedPtr changes

[Michel Hermier]

2006/1/23, André Wöbbeking <Woebbeking at onlinehome.de>:
>
> On Monday 23 January 2006 19:37, Michel Hermier wrote:
> > Hi,
> > I just commited the explicit constructor patch for KSharedPtr.
>
> Thanks, it was really time for that :-)


Hehe ;)

> There are less than 10 files to adapt.
> > So please maintainers adapt the remaining files the why you like.
>
> I did, and some usages of KSharedPtr looks a bit scary, i.e.
> KSharedConfig::openConfig().


This one is not really scary. It's a cache of raw pointer and there are no
other way of doing it.
If the config hash use shared pointer, the shared config will be in the
cache *forever*.
It's not scary to manipulate raw pointer of shared pointer inside of it's
factory.
It's way more scary to use raw pointer outside of it's factory.

Shouldn't KSharedPtr<T>& operator= ( T* p ) be also removed?


I also thougth so at first, but I really think it should be here since it's
as dangenrous as calling the operator= with a fresh KSharedPtr. Plus the
fact that the class mimic the QSharedDataPointer API.
I would say it's safer to call attach() since you should really know what
you are doing with it, and we can grep for it just in case.

BTW, did you think about my suggestion to use the boost API (i.e.
> attach() vs. reset(), data() vs. get(), ...)?


I don't really have an opinion about that. It's a religion talk. I think we
must at least follow the Qt naming convention first. Maybe we can also add
some helper method to be compatible with the boost convention, but I don't
really care since these are one liners.

cheers,
    Michel

Next steps for KSharedPtr:
- manually deinling clear and detach (isUnique?) for speed (in debug mode).
- adding swap method to speed up shared ptr swap ? (using qSwap here may be
to much slow?)
  (thx to andré for *making* me looking at the boost documentation :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060124/c31f37c9/attachment.htm>