Why no reset() function?

[Morris Dovey]

Often programs will have memory leaks, so if they are run over long
times then it's necessary to restart them sometimes. With a reset()
function, they could effectively restart themselves by freeing their
memory without needing to be closed and reopened.

A memory leak constitutes a program error. Programs without such
errors don't need any of the remedies you're suggesting.

 

[Prad]

Hello,

In BASIC there is a very useful function called RESET that clears out
all the stored variables and restores memory state to startup.

Why is there not a similar function in C? It should free up all heap
allocations without having to free them individually.

Often programs will have memory leaks, so if they are run over long
times then it's necessary to restart them sometimes. With a reset()
function, they could effectively restart themselves by freeing their
memory without needing to be closed and reopened.

 

[Ian Collins]

Hello,

In BASIC there is a very useful function called RESET that clears out
all the stored variables and restores memory state to startup.

Why is there not a similar function in C? It should free up all heap
allocations without having to free them individually.

Because it would probably be disastrous. If you wish to do this, just
run your application from another, exit periodically and have the parent
restart the application.

Often programs will have memory leaks, so if they are run over long
times then it's necessary to restart them sometimes. With a reset()
function, they could effectively restart themselves by freeing their
memory without needing to be closed and reopened.

No, it is simply necessary to clean up your mess and not leak memory.

 

[Richard Tobin]

In BASIC there is a very useful function called RESET that clears out
all the stored variables and restores memory state to startup.

I don't recall that in any version of Basic I used, but it was
a long time ago.

Why is there not a similar function in C? It should free up all heap
allocations without having to free them individually.

Why not just run the program again?

Presumably it existed in whatever Basic you used because it's an
interactive, interpreted environment. C programming isn't usually
done like that.

-- Richard

 

[Tomás Ó hÉilidhe]

Prad:

Hello,

In BASIC there is a very useful function called RESET that clears out
all the stored variables and restores memory state to startup.

Why is there not a similar function in C? It should free up all heap
allocations without having to free them individually.

Such a thing could be coded quite easily. I'd hijack "malloc" and keep a
table of all allocated memory, maybe something like:

void *allocs[256] = {};

void **p_current_alloc = allocs;

void *my_malloc(size_t const len)
{
return *p_current_alloc++ = malloc(len);
}

void Reset(void)
{
void **p = allocs;

do free(*p++);
while (p_current_alloc != p);

p_current_alloc = allocs;
}

Of course tho, you'd be better off using malloc properly.

 

[Robert Latest]

In BASIC there is a very useful function called RESET that clears out
all the stored variables and restores memory state to startup.

You could try setjmp() and longjmp(), but that won't clear dynamically
allocated storage.

Often programs will have memory leaks, so if they are run over long
times then it's necessary to restart them sometimes.

s/restart/fix
s/sometimes/once

robert

 

[Eric Sosman]

You could try setjmp() and longjmp(), but that won't clear dynamically
allocated storage.


s/restart/fix
s/sometimes/once

The counsel of perfection is unassailable, as far as it
goes -- but only that far. Programming is largely an economic
activity: You write (and enhance, and fix, and rewrite ...) a
program to accomplish some purpose or other, the idea being
that the effort expended on the program will be less than it
would have taken to accomplish the same purpose without the
program's aid.

... which means that the decision to spend further effort
fixing it or to spend less effort on a sloppy work-around is
also an economic decision. It calls for a certain amount of
guesswork about the likely future use(s) of the program, too:
How much will it hurt if I use the work-around today and then
wind up needing to do the full-scale fix later anyhow? But it's
not a law of the universe that every bug must be squeezed out
of every program! Sometimes the expedient course, and even the
sensible course, is to use the program as it stands, bugs and
all, and to tolerate those that you must.

And even if you find this attitude defeatist and perhaps
loathsome, consider: The fact that a program consumes more and
more memory as time passes and eventually exhausts it is not
proof of a memory leak. The key word is "fragmentation," and
in TAOCP section 2.5 Knuth reports on a proof by J.M. Robson
that *all* allocation methods are vulnerable to fragmentation
unless they are able to move allocated blocks: "[...] even when
blocks are restricted to be of sizes 1 and 2, overflow might
occur with memory only about 2/3 full, no matter what allocation
algorithm is used!"

 

[testdemo]

Just testing...

You could try setjmp() and longjmp(), but that won't clear dynamically
allocated storage.


s/restart/fix
s/sometimes/once

The counsel of perfection is unassailable, as far as it
goes -- but only that far. Programming is largely an economic
activity: You write (and enhance, and fix, and rewrite ...) a
program to accomplish some purpose or other, the idea being
that the effort expended on the program will be less than it
would have taken to accomplish the same purpose without the
program's aid.

... which means that the decision to spend further effort
fixing it or to spend less effort on a sloppy work-around is
also an economic decision. It calls for a certain amount of
guesswork about the likely future use(s) of the program, too:
How much will it hurt if I use the work-around today and then
wind up needing to do the full-scale fix later anyhow? But it's
not a law of the universe that every bug must be squeezed out
of every program! Sometimes the expedient course, and even the
sensible course, is to use the program as it stands, bugs and
all, and to tolerate those that you must.

And even if you find this attitude defeatist and perhaps
loathsome, consider: The fact that a program consumes more and
more memory as time passes and eventually exhausts it is not
proof of a memory leak. The key word is "fragmentation," and
in TAOCP section 2.5 Knuth reports on a proof by J.M. Robson
that *all* allocation methods are vulnerable to fragmentation
unless they are able to move allocated blocks: "[...] even when
blocks are restricted to be of sizes 1 and 2, overflow might
occur with memory only about 2/3 full, no matter what allocation
algorithm is used!"

 

[dj3vande]

Just testing...

You fail.
Test posts go in newsgroups whose names end in ".test".
Quoting an entire post to top-post a content-free comment is a Bad Idea
no matter where you do it.
Bogus email addresses should not resolve to real domains.


dave

 

[Robert Latest]

And even if you find this attitude defeatist and perhaps
loathsome,

I don't. It's simple pragmatism. But I had the impression that the OP didn't
want to worry about memory management at all.

robert