On 19 Dec 2013, at 11:29, Tim Blechmann <[email protected]> wrote: >>> Should Qt clean-up dynamically allocated reachable pointers, or is this >>> useless / pointless work? > [snip] >> 2) static leak, which is when the pointer is overwritten at shutdown without >> being freed > i wonder: what is the definition of "shutdown"? > in many applications it is perfectly fine to allocate memory without > freeing them ...
Worth mentioning that freeing memory takes no time, so skipping freeing memory to optimize shutdown time is just silly. It’s the C++ism of destroying an object that takes time in connection to freeing memory. Complex destructors are one of two things that makes an app slow to quit, beyond whatever the app _wants_ to do on shutdown. The other case where an app would spend measurable time on a clean shutdown is if it has dirty written pages to mapped memory that need to be flushed. Should apps explicitly free all memory, that’s not only about tracking ill-managed memory. If your app manages its memory well, explicit freeing is irrelevant for the app as it stands. Whether you ask the OS to reclaim the memory or not before it does so itself does nothing for shutdown time. But it’s impractical to fail to free memory on exit, because it makes it darn hard to discover ill-managed memory. And since freeing memory is so connected to destroying objects in C++, and running destructors, failing to explicitly free memory will typically also fail to call those destructors. It’s rare to find a C++ class with a non-empty destructor that takes into account what could happen if the memory were freed, as it always is, but the destructor was not run. +1 to explicitly destroying / freeing all memory. It does nothing for shutdown time, but makes it easier to discover ill-managed memory. And destructors should always be called for any instance of a class that has a destructor implementation. This goes for real-world apps btw, in examples / snippets in books / online and so on, memory management is just noise. Andreas _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
