[Development] Qt's Leak-on-exit policy

Thiago Macieira thiago.macieira at intel.com
Thu Dec 19 01:52:06 CET 2013


On quarta-feira, 18 de dezembro de 2013 16:41:08, Alex Montgomery wrote:
> I think Thiago made a great point when he said, "Objects not properly
> destroyed at shutdown could be an indication of something else wrong". The
> thing that scares me most about the philosophy that we don't have to delete
> reachable dynamically allocated objects is that those objects never have
> their destructors called, and those destructors might do important things
> besides freeing memory. I personally still believe that Qt as a whole
> should strive to not have any on-exit leaks, because that breaks the
> implicit agreement we share as object-oriented programmers. Destructors are
> designed to be called.

Note I said we should always investigate. But if the result of the 
investigation is that it's harmless, I said I didn't know if we should fix 
things.

I like Andreas's proposal. It would be the best of both worlds.

But it's unworkable. At which point should free() become no-op? Just after 
main() returns or exit() starts executing? Well, the application can continue 
running for a long time after that happens, so not actually freeing memory 
could leak to it blowing up.

The best solution might be a leak suppression information to valgrind, or use 
VALGRIND_FREELIKE_BLOCK.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131218/ef9e6986/attachment.sig>


More information about the Development mailing list