KSharedPtr changes

[André Wöbbeking]

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

I don't understand. What is dangerous in the latter case?

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

Yupp.

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

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

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 :)

:-)


Cheers,
André