From kde-core-devel Tue Jan 24 16:52:37 2006 From: Michel Hermier Date: Tue, 24 Jan 2006 16:52:37 +0000 To: kde-core-devel Subject: Re: KSharedPtr changes Message-Id: <2e631f490601240852m62e2bf8cw () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113812156511357 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------=_Part_12990_20007464.1138121557360" ------=_Part_12990_20007464.1138121557360 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2006/1/24, Andr=E9 W=F6bbeking : > > On Tuesday 24 January 2006 01:08, Michel Hermier wrote: > > 2006/1/23, Andr=E9 W=F6bbeking : > > > 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& operator=3D ( 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=3D with a fresh > > KSharedPtr. > > I don't understand. What is dangerous in the latter case? doing fooPtr =3D bar; or fooPtr =3D 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=E9 for *making* me looking at the boost documentation :) I looked at it yesterday and qt don't provide an atomic swap pointers metho= d :S I wonder how to do it. Cheers Michel ------=_Part_12990_20007464.1138121557360 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

2006/1/24, Andr=E9 W=F6bbeking <= ;Woebbeking@onlinehome.de&g= t;:
On Tuesday 24 January 2006 01:08, Michel Hermier wrote:
> 2006/1/23, = Andr=E9 W=F6bbeking <Woebbek= ing@onlinehome.de>:
> > On Monday 23 January 2006 19:37, Mi= chel Hermier wrote:

> > I did, and some usages of KSharedPtr looks a bit scary, i= .e.
> > KSharedConfig::openConfig().
>
> This one is n= ot really scary.

Well, if I'm not totally wrong you can't get differ= ent shared pointers
for the same object and this leads to dangling pointers.

> &g= t; Shouldn't KSharedPtr<T>& operator=3D ( T* p ) be also removed?=
>
> I also thougth so at first, but I really think it should b= e here
> since it's as dangenrous as calling the operator=3D with a fresh> KSharedPtr.

I don't understand. What is dangerous in the latt= er case?

doing
fooPtr =3D bar;
or
fooPtr =3D = FooPtr(bar);
is the same for me.
It's not *dangerous* because it can't be t= he 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 point= ers (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. g= et(), ...)?
>
> 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 eve= n a must
be.

I know that, but I would not do it till it's i= n the next standard.

> I think we must at least follow the Qt naming convention first. Maybe<= br>> we can also add some helper method to be compatible with the boost<= br>> 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 whis= h, but don't remove the QTL ones.

> Next steps for KSharedPtr:
> - manually deinling clear and detac= h (isUnique?) for speed (in debug
> mode).

What is deinling?

de-inlining .... it was really late when I wrote th= e mail ;)=20

>= ; - adding swap method to speed up shared ptr swap ? (using
> qSwap h= ere may be to much slow?)
>   (thx to andr=E9 for *making* me looking at the boost d= ocumentation :)

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

Cheers
     Michel
------=_Part_12990_20007464.1138121557360--