Woebbeking at onlinehome.de
Tue Jan 24 16:13:24 GMT 2006
On Tuesday 24 January 2006 01:08, Michel Hermier wrote:
> 2006/1/23, André Wöbbeking <Woebbeking at onlinehome.de>:
> > On Monday 23 January 2006 19:37, Michel Hermier wrote:
> > I did, and some usages of KSharedPtr looks a bit scary, i.e.
> > KSharedConfig::openConfig().
> This one is not really scary.
Well, if I'm not totally wrong you can't get different shared pointers
for the same object and this leads to dangling pointers.
> > 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
I don't understand. What is dangerous in the latter case?
> Plus the fact that the class mimic the QSharedDataPointer
> 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.
It's not really religious. boost's shared pointer is part of the next
standard, so a compliant API is at least a should be if not even a must
> 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.
That's a good idea as all QTL classes also have a STL API.
> Next steps for KSharedPtr:
> - manually deinling clear and detach (isUnique?) for speed (in debug
What is deinling?
> - 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 :)
More information about the kde-core-devel