KSharedPtr changes

[Michel Hermier]

2006/1/24, André Wöbbeking <Woebbeking at onlinehome.de>:
>
> 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?


doing
fooPtr = bar;
or
fooPtr = FooPtr(bar);
is the same for me.
It's not *dangerous* because it can't be the source of dandling pointers so
I think it's safe to use it.
It's only a source of dandling pointer if you are doing bad stuff with the
raw pointers (which can also be done with the constructor).

> 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 know that, but I would not do it till it's in the next standard.

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


For now it's not a part of it, so I don't care. Do as you whish, but don't
remove the QTL ones.

> Next steps for KSharedPtr:
> > - manually deinling clear and detach (isUnique?) for speed (in debug
> > mode).
>
> What is deinling?
>

de-inlining .... it was really late when I wrote the mail ;)

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


I looked at it yesterday and qt don't provide an atomic swap pointers method
:S
I wonder how to do it.

Cheers
     Michel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060124/fd31925f/attachment.htm>