[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