[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    KSharedPtr changes
From:       Michel Hermier <michel.hermier () gmail ! com>
Date:       2006-01-14 11:54:42
Message-ID: 2e631f490601140354n6942911j () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi,
I would like commit the attached patch (ksharedptr.h.diff).
It does:
- separate raw pointer operator from ksharedptr operators.
- add a clear method to make the pointer null.
- make the method attach only usable on raw pointer.
  (since it's a *low level* method and that the operator = handle all the
cases)
  I still wonder if I should make that method a private/protected one.

Other than that I would like to know the opinion of people if I make the
main constructor an explicit one.
Like that we could at least see while coding bugs like:

void foo(KSharedPtr<Bar> bar);

Bar *foofoo()
{
    Bar *bar = new Bar();
    foo(bar);
    return bar; // bar is now a dandling pointer
}

One main disaventage of that is that we can't use the "KSharedPtr<Foo> foo =
bar;" syntax.
We must use the "KSharedPtr<Foo> foo(bar);" syntax.

I also attached the whole kdelibs kshared explicit constructor patch for
reference to show that's it's quite simple to convert to explicit
constructor.
It adds some not pretty code at some place, but it's a private diff and I
don't intend to commit it like this.

Michel

[Attachment #5 (text/html)]

Hi,<br>I would like commit the attached patch (ksharedptr.h.diff).<br>It does:<br>- \
separate raw pointer operator from ksharedptr operators.<br>- add a clear method to \
make the pointer null.<br>- make the method attach only usable on raw pointer. \
<br>&nbsp; (since it's a *low level* method and that the operator = handle all the \
cases)<br>&nbsp; I still wonder if I should make that method a private/protected \
one.<br><br>Other than that I would like to know the opinion of people if I make the \
main constructor an explicit one. <br>Like that we could at least see while coding \
bugs like:<br><br>void foo(KSharedPtr&lt;Bar&gt; bar);<br><br>Bar \
*foofoo()<br>{<br>&nbsp;&nbsp;&nbsp; Bar *bar = new Bar();<br>&nbsp;&nbsp;&nbsp; \
foo(bar);<br>&nbsp;&nbsp;&nbsp; return bar; // bar is now a dandling pointer \
<br>}<br><br>One main disaventage of that is that we can't use the \
&quot;KSharedPtr&lt;Foo&gt; foo = bar;&quot; syntax.<br>We must use the \
&quot;KSharedPtr&lt;Foo&gt; foo(bar);&quot; syntax.<br><br>I also attached the whole \
kdelibs kshared explicit constructor patch for reference to show that's it's quite \
simple to convert to explicit constructor. <br>It adds some not pretty code at some \
place, but it's a private diff and I don't intend to commit it like \
this.<br><br>Michel<br>


["ksharedptr.h.diff" (application/octet-stream)]
["kdelibs-explicit_KSharedPtr.diff" (application/octet-stream)]

[prev in list] [next in list] [prev in thread] [next in thread]