<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);

</div>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).

<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

> 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(), ...)?

<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>