Prad wrote:

> 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.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

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.

Prad wrote:
> 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.

--
Ian Collins.

In article <slrnfq9vev.dk6.nospam@nospam.invalid>,
Prad <nospam@nospam.com> wrote:

>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
--
:wq

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.

--
Tomás Ó hÉilidhe

Prad wrote:

> 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

Robert Latest wrote:
> Prad wrote:
>
>> 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

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!"

--
Eric Sosman
esosman@ieee-dot-org.invalid

Just testing...

Eric Sosman Wrote:

> Robert Latest wrote:
> > Prad wrote:
> >
> >> 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
>
> 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!"
>
> --
> Eric Sosman
> esosman@ieee-dot-org.invalid