KAutoPointer: a new autoptr class for QPointer
kloecker at kde.org
Fri Jul 10 15:01:04 BST 2009
On Friday 10 July 2009, Lubos Lunak wrote:
> Dne středa 08 července 2009 19:19:43 David Jarvie napsal(a):
> > There is a widespread issue in KDE applications, described by Frank
> > Osterfeld at http://www.kdedevelopers.org/node/3919, where if an
> > application is displaying a modal dialog when it receives a quit
> > signal, the dialog will be deleted by its parent's destructor and
> > after the exec() call returns, the application is likely to crash
> > due either to double deletion of the dialog, or use of the dangling
> > pointer.
> > A new template class for kdelibs, KAutoPointer, is proposed in
> > http://reviewboard.kde.org/r/955/, which provides a combination of
> > a QPointer and and autoptr so that double deletion can be avoided,
> > and dangling pointers can be detected.
> I disagree with both the analysis of the problem and the proposed
> I would argue that the problem in
> http://www.kdedevelopers.org/node/3919 is a problem on its own and as
> such the solution is DONOTDOTHAT. I believe that quitting an
> application with a modal dialog open should not quit, but instead
> should require the user to close the dialog first.
Obviously, this situation arises if the user logs out while there is
still some application showing a modal dialog. IMHO the user should not
be obligated to close all modal dialogs if he wants to log out.
> That said, I would strongly support it if KDE finally embraced the
> 90's and started using some kind of a scoped pointer. By which is
> mean something that basically just takes ownership of the object and
> does delete in the dtor. Qt API somehow discourages the usage of the
> stack and especially less experienced C++ developers ofter write
> stuff like:
> void foo()
> Object* o = new Object;
> delete o;
> Which is completely unnecessary and we have numbers of leaks because
> of this, as soon as the control flow becomes even slightly more
> complicated. I would of course rather see this with the object simply
> allocated on the stack, but using a scoped pointer here is still much
> better. The same with classes, which should rather use scoped
> pointers for objects they own rather than listing delete calls in the
I wholeheartedly agree with this. Unfortunately, there appears to be
quite some aversion against using boost's pointer template classes (a
trivial compile time dependency) in KDE, so using scoped pointers will
not happen until Qt 4.6. I'd really love to know what technical reasons
this aversion is based on.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel