[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