Re: Newbies don't learn C++
Leigh Johnston wrote:
On 13/01/2011 14:45, Dilip wrote:
On Jan 13, 9:18 am, Leigh Johnston<le...@i42.co.uk> wrote:
A memory leak is the failure to deallocate that which was allocated
before program termination, end of story.
A dynamically allocated singleton object whose lifetime extends until
the application shuts down is leaking memory? You are stretching the
definition of a "leak".
If during program termination the C/C++ runtime or the OS has to cleanup
a memory allocation due to a lack of a paired deallocation then that
memory allocation is a leak yes.
If you want to define this term like that, so be it. But then, who cares
if a program leaks? After all, the memory is released on shutdown[0]. Yes,
these "leaks" can be detected automatically and there are easy ways to
avoid them, basically discipline in low-level resource management will do,
but they don't say anything about the runtime behaviour of the program.
Instead, the IMHO important property of a resource leak is that resources
are allocated and not used any more but also not released. In that sense,
I'd say you need at least two stages in the program, one that allocates an
object and a second that neither releases nor uses it. Further, I would
say that some steps are then usually repeated in a loop, causing an
increasing memory consumption with each repetition.
Example:
int main() {
vector<char> f = read_cfg_file();
settings s = parse_cfg(f);
// (1)
run_program(s);
}
At point (1), "f" becomes unused but remains allocated and thus
constitutes a memory leak according to my definition. It is paired with a
proper deallocation on program termination, so it isn't one in your
definition. I find mine more useful when talking about a program.
Even more so when considering a server process:
int main() {
list<connection> clients;
try {
while(true) {
connection c = accept_connection();
if(c)
clients.push_back(c);
service_connections(clients);
}
} catch(...) {
}
}
This program will not terminate on its own but continue to allocate new
connections until it runs out of memory because it fails to clean up or
otherwise limit the number of connections. It will then release existing
connections, so allocations and deallocations are paired.
You are also forgetting that an object
can become unreachable and yet not be a leak (delete this).
But if you have a this-pointer, the object is not unreachable. The fact
that the pointer was never explicitly declared anywhere doesn't matter:
struct foo {
void bar() {
delete this;
}
};
int main() {
(new foo)->bar();
}
There is no visible pointer to the allocated object, but it is still
reachable and deleted "correctly". I think this is also what first Paavo
and then James were trying to express.
Cheers!
Uli
[0] Yes, assuming the non-guaranteed but virtually omnipresent support by
the environment.