Hello, 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.
That being said, I like Sorvig's ideas about supporting both the needs of leak checkers and the needs of near-instant shutdown, if that is at all possible. Regards, Alex On Wed, Dec 18, 2013 at 4:17 PM, Andreas Hartmetz <ahartm...@gmail.com>wrote: > On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote: > > On 18 Dec 2013, at 01:22, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > > If it turns out that the failure to destroy is harmless, I'm not sure > we > > > should do anything. If it's harmless, that means the extra work > required > > > to > > > free the memory is wasted, since it has no benefit to anyone. Just > wasted > > > CPU cycles. > > > > An interesting trend on the Apple platforms is not having a clean app > > shutdown. The OS will terminate the process when the user indicates it’s > no > > longer in use, for example by switching to another app or closing all the > > application windows. > > > > This suggests two levels of support from Qt: > > > > 1) Support a clean shutdown for applications and/or operating systems > that > > require this. We go the extra mile to make sure Qt works well with leak > > detecting tools. > > > > 2) Support “process terminate” style shutdown for applications that > require > > a fast shutdown. This shutdown could be initiated by the OS or by the > > application. The requirements for this lie in the area of the application > > not doing much processing on shutdown (auto-saving settings immediately > for > > example), and Qt protecting itself from termination during critical > > operations such as writing QSettings to disk or having a background file > > transfer in progress. > > > Hello. > This is not supposed to be a serious contribution to the discussion. > This is about an unworkable but fun idea. > > 2) reminds me of a crazy idea I've had once... freeing memory (not > object destruction!) at application exit really serves no other purpose > than making leak checkers happy. Not saying that this isn't an > important goal, btw. So shutdown could be accelerated by putting > free() into a special shutdown mode that just immediately returns. > Of course there would be a conditional branch somewhere, unless you > modified the GOT entry for free() or something. That would add a > runtime overhead, which is worse than slightly slower shutdown. > > I don't even know how much time is spent in free() at shutdown, and > faster shutdown isn't a very important goal anyway. > Instantaneous shutdown (see 2)) seems more useful in practice. > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development