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

[Albert Astals Cid]

On Wednesday 18 December 2013 16:52:06 Thiago Macieira wrote:
> 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.

But that needs:
 a) A central place to write down those investigated places that have been 
proven to be harmless so that not N people waste their time investigating
 b) Reinvestigation every X time to make sure it is still harmless

Is it not just easier to add the "delete" and then a) nor b) are needed?

Cheers,
  Albert

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