From kde-core-devel Tue Jan 24 00:08:59 2006 From: Michel Hermier Date: Tue, 24 Jan 2006 00:08:59 +0000 To: kde-core-devel Subject: Re: KSharedPtr changes Message-Id: <2e631f490601231608y505ea7a5l () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113806135321185 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------=_Part_3559_7606085.1138061339012" ------=_Part_3559_7606085.1138061339012 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2006/1/23, Andr=E9 W=F6bbeking : > > 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& 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. 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=E9 for *making* me looking at the boost documentation :) ------=_Part_3559_7606085.1138061339012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2006/1/23, Andr=E9 W=F6bbeking <Woebbeking@onlinehome.de>:
On Monday 23 January 2006 19:37, Michel Hermier wrote:
> Hi,
> = I just commited the explicit constructor patch for KSharedPtr.

Thank= s, it was really time for that :-)

Hehe ;)

> There = are less than 10 files to adapt.
> So please maintainers adapt the re= maining files the why you like.

I did, and some usages of KSharedPtr looks a bit scary, i.e.
KSh= aredConfig::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 cac= he *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.

Sho= uldn't KSharedPtr<T>& operator=3D ( T* p ) be also removed?

I also thougth so at first, but I really think it should be here s= ince it's as dangenrous as calling the operator=3D 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 d= oing 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 rel= igion 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 c= onvention, but I don't really care since these are one liners.

cheers,
    Michel

Next steps for KSharedP= tr:
- 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?)=20
  (thx to andr=E9 for *making* me looking at the boost documentati= on :)

------=_Part_3559_7606085.1138061339012--