> B) Somehow signal to debuggers that the leak is deliberate
This would be a really tough sell. It would be a lot of complexity, both in tooling and the standard, for very little gain.
The question is more about whether this is something that warrants a library facility like you proposed or not.
I don’t think it does. Instead of an atexit approach like you presented, I think it would be more principled to write it as one normally would with proper cleanup. Then you can simply put an #ifdef around the cleanup that can be done by the OS, as an optimization for your program. Better than malloc here, you could use unique_ptrs and conditionally .release() at the end.
> However if 'c' is only 120 milliseconds quicker to die than 'b', then I won't bother with 'c', I'll just have 'a' and 'b'.
I’m glad you brought this up. I am highly skeptical that cleanup would matter at all for a program’s exit performance - freeing is fast. But if you can provide evidence and rationale that this is a significant issue then it’s more worth taking the time to look at.
But to reiterate, I think doing this with unique pointers and conditionally calling .release, or something similar, is a much more principled way of doing this and it’s something better done on the application level than by the standard library.
Jeremy
On Saturday, October 12, 2024, Jeremy Rifkin wrote:
How about using a preprocessor define to clean up the allocations properly when using memory tooling or even just in debug in general while letting it leak in release.
That's exactly what I'm saying "std::deliberate_leak" should do (see the implementation in my original post). Or maybe it could do one of two things:
A) Deallocate all leaks before death of process
B) Somehow signal to debuggers that the leak is deliberate
I think in future my program will have 3 builds in future:
a - Debug
b - Release Without Leaks
c - Release With Leaks
However if 'c' is only 120 milliseconds quicker to die than 'b', then I won't bother with 'c', I'll just have 'a' and 'b'.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals