KSharedPtr changes

[Michel Hermier]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060114/734fc76c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ksharedptr.h.diff
Type: application/octet-stream
Size: 2281 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060114/734fc76c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-explicit_KSharedPtr.diff
Type: application/octet-stream
Size: 28161 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060114/734fc76c/attachment-0001.obj>