C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Deliberate memory leak

From: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Date: Sat, 12 Oct 2024 13:02:07 -0500
Hi Frederick,

> 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 Sat, Oct 12, 2024 at 10:43 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-10-12 18:02:23