> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?
You should get in the habit of always doing The Right Thing, even when
you believe that right at that moment, you would not need to do The
Right Thing. If you teach yourself to rely on shortcuts, you will sooner
or later cut a short somewhere it shouldn't be cut.
Richard
>Should we always free memory allocated through malloc() in a process
>even just before return from main(in non-server application).If the
>OS does it automatically, is free() an avoidable overhead?
Do you think if the OS does it that there is no overhead. Someone
always pays; there is no free lunch. You reserved the resource. It
seems only fair you should release it. You should also fclose any
file you fopen.
Remove del for email
That's a question for your OS to answer. C doesn't care what happens
after your program has exited. If you want your code to be independent
of the target platform, you should of course free() all you can, just in
case.
It's at least good style, and I've seen operating systems that did not
clean up behind you.
> If the
> OS does it automatically, is free() an avoidable overhead?
IMHO, no. But this is rather an opinion than a fact. I would do it
for matters of good style. Consider that you change the program later
on such that the single allocation that is now released by the operating
system is then run multiple times, and you leak memory on each iteration -
this might become a problem.
Besides - I wouldn't use malloc() in C++ - that's the first point.
So long,
Thomas
> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?
The answer to your first question (I assume it is a question despite
the lack of a '?'), is yes, you should.
Your second incorrectly punctuated question is subjunctive, based on
whether or not "the OS" does it automatically.
Do you think that "the OS" you are using is actually "THE OS", that is
the only one? There are some operating systems that claim to release
all memory allocated by a program when it exits. There are at least
some circumstances where at least some of these operating systems do
not always perform that task correctly.
What do you care about overhead when an application is exiting?
Professional quality programming demands proper initialization and
proper clean up.
Not to mention what happens when somebody else wants to take the
original program and use it as a subroutine in a bigger program some
day.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
yes. but for complex programs freeing is good as then special tools
can be used to detect lost unfreed memory - which can cause
long-running processes to misbehave as it builds up...
Bye.
Jasen
If a program does some deallocation, then you should probably be consistent
and try to balance every allocation with a deallocation. But there are many
applications in which all you ever do is allocate, and abort if you ever run
out of memory. In this case, it's hardly worth going to the trouble.
For instance, I just finished writing a command line directory lister (a
fancier version of "ls") that allocates a chunk of memory to hold each file
name and its attributes. Once the list of files is built and sorted, it is
written out, and the program terminates. In that case, there is no point in
going through the list and freeing everything. When the program exits, the
few large pieces of memory that the C library requested from the OS are
freed by the OS much more quickly than the C library could deallocate the
potentially huge number of tiny pieces that the program allocated
internally.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com