[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KSharedPtr changes
From: Michel Hermier <michel.hermier () gmail ! com>
Date: 2006-01-24 16:52:37
Message-ID: 2e631f490601240852m62e2bf8cw () mail ! gmail ! com
[Download RAW message or body]
2006/1/24, André Wöbbeking <Woebbeking@onlinehome.de>:
>
> On Tuesday 24 January 2006 01:08, Michel Hermier wrote:
> > 2006/1/23, André Wöbbeking <Woebbeking@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
[Attachment #3 (text/html)]
<br><br><div><span class="gmail_quote">2006/1/24, André Wöbbeking <<a \
href="mailto:Woebbeking@onlinehome.de">Woebbeking@onlinehome.de</a>>:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Tuesday 24 January 2006 \
01:08, Michel Hermier wrote:<br>> 2006/1/23, André Wöbbeking <<a \
href="mailto:Woebbeking@onlinehome.de">Woebbeking@onlinehome.de</a>>:<br>> \
> On Monday 23 January 2006 19:37, Michel Hermier wrote: <br><br>> \
> I did, and some usages of KSharedPtr looks a bit scary, i.e.<br>> \
> KSharedConfig::openConfig().<br>><br>> This one is not really \
scary.<br><br>Well, if I'm not totally wrong you can't get different shared \
pointers <br>for the same object and this leads to dangling \
pointers.<br><br>> > Shouldn't KSharedPtr<T>& operator= ( \
T* p ) be also removed?<br>><br>> I also thougth so at first, but I \
really think it should be here <br>> since it's as dangenrous as calling \
the operator= with a fresh<br>> KSharedPtr.<br><br>I don't understand. \
What is dangerous in the latter case?</blockquote><div><br>doing<br>fooPtr \
= bar;<br>or<br>fooPtr = FooPtr(bar); <br></div>is the same for me.<br>It's \
not *dangerous* because it can't be the source of dandling pointers so I \
think it's safe to use it.<br>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). <br><br><blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: \
1ex;">> Plus the fact that the class mimic the \
QSharedDataPointer<br>> API.<br>> I would say it's safer to call \
attach() since you should really know <br>> what you are doing with it, \
and we can grep for it just in case.<br><br>Yupp.<br><br>> > BTW, did \
you think about my suggestion to use the boost API (i.e.<br>><br>> \
> attach() vs. reset(), data() vs. get(), ...)? <br>><br>> I don't \
really have an opinion about that. It's a religion talk.<br><br>It's not \
really religious. boost's shared pointer is part of the next<br>standard, \
so a compliant API is at least a should be if not even a must \
<br>be.</blockquote><div><br>I know that, but I would not do it till it's \
in the next standard. <br></div><br><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt \
0.8ex; padding-left: 1ex;"> > 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. <br><br>That's a good idea as all QTL classes \
also have a STL API.</blockquote><div><br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> \
> Next steps for KSharedPtr:<br>> - manually deinling clear and \
detach (isUnique?) for speed (in debug<br>> mode).<br><br>What is \
deinling?<br></blockquote><div><br>de-inlining .... it was really late when \
I wrote the mail ;) <br><br></div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt \
0.8ex; padding-left: 1ex;">> - adding swap method to speed up shared ptr \
swap ? (using<br>> qSwap here may be to much slow?) <br>> \
(thx to andré for *making* me looking at the boost documentation \
:)</blockquote><div><br>I looked at it yesterday and qt don't provide an \
atomic swap pointers method :S<br>I wonder how to do \
it.<br></div><br>Cheers <br> Michel<br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic