--- Comment #11 from Jonathan Wakely <redi at gcc dot> ---
(In reply to frankhb1989 from comment #9)
> Following your narrow definition of "leak", it implies that any system using
> GC could never leak. That's absurd.

Wikipedia: "a memory leak is a type of resource leak that occurs when a
computer program incorrectly manages memory allocations in such a way that
memory which is no longer needed is not released."

This memory is still needed up until exit.

Google: "a failure in a program to release discarded memory, causing impaired
performance or failure."

This is not discarded memory, and does not impair performance or cause failure.

MSDN: "When an application dynamically allocates memory, and does not free that
memory when it is finished using it, that program has a memory leak."

The memory is in use right until exit, so the application hasn't finished using

> A leak of resource may occur when the client (either the code of the
> application or the underlying runtime responsible to deal with the allocated
> resource) has lost the control of the lifetime of that resource.

The runtime hasn't lost control of it.

> If that
> resource is not needed and there is no other way to transfer the ownership,
> it is leaked.

It's still needed.

> Still reachable memory can be leaked, depends on the
> intention. Sometimes the leak detector has no clue to figure out whether the
> memory should be still here or not, but we humans have, though it may be
> arguable.
> The situation necessitating "exit()" to cleanup almost always meets the
> condition of leak above. This is feasible only when the users can rely on
> the fact that the hosting environment will cleanup the (already leaked)
> resources of that program (likely in some magical ways unrelated to the
> program itself). This is not portable in general.

We're not talking about arbitrary resources in the general case, we're talking
about heap memory in the GNU C++ runtime. That memory is freed on exit. If you
want to waffle about it further please take it somewhere else.

 (And abuse of exit() will
> easily cause other problems.) I don't see "most" programs do that seriously
> because it is not easy to guarantee the behavior predictable.

Reply via email to