I’ve worked with a handful of developers who were just… careless and cavalier about exit-time destructors, global statics, and more generally, what happens when the user exits the app. Race conditions-on-exit, crashes-on-exit and general sloppiness in cleaning up what was allocated. There’s an attitude out there of “who cares what happens after the user hits the X to exit? The process is dying anyway!” I’ve always considered it a pride/craftsmanship issue but it can be hard to get other developers to care about the details of __cxa_atexit, the order that things happen in, and so on. Long way of saying I appreciate this article!
> There’s an attitude out there of “who cares what happens after the user hits the X to exit? The process is dying anyway!”
Why _should_ we care? Even here, you're not providing a technical justification but instead make a quixotic appeal to emotion. I have listened to talks from HFT guys where they claim to deliberately ignore memory leaks if it produces faster code. They just buy more ram, and rely on the OS clean it up at the end of the trading day. Seems reasonable to me.
The article fails to mention that __cxa_atexit allocates and therefore can fail, but the interface does not permit error reporting. This is probably more important to address for the thread-local destructor registration (__cxa_thread_atexit).
std::quick_exit() also works, though you can decide if it's worthwhile to allow parts of the program to register functions to be called at quick exit time.
That's not a memory leak (when done at top level) because it's reachable for the entire execution of the program. Memory is only leaked if it's still allocated once it's no longer reachable.
[+] [-] ryandrake|2 years ago|reply
[+] [-] patrick451|2 years ago|reply
Why _should_ we care? Even here, you're not providing a technical justification but instead make a quixotic appeal to emotion. I have listened to talks from HFT guys where they claim to deliberately ignore memory leaks if it produces faster code. They just buy more ram, and rely on the OS clean it up at the end of the trading day. Seems reasonable to me.
[+] [-] fweimer|2 years ago|reply
[+] [-] frozenport|2 years ago|reply
[+] [-] Negitivefrags|2 years ago|reply
I tend to add that to software I write inside an #ifdef NDEBUG.
The OS does the work faster.
[+] [-] leg|2 years ago|reply
[+] [-] spacechild1|2 years ago|reply
> Note that this does not create a memory leak, since the pointer/reference is part of the root set.
Can someone explain this to me? How would that not be a memory leak? What does 'root set' mean in this context?
[+] [-] josephcsible|2 years ago|reply