Should you free your pointers?

B

Billy Mays

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

Example:
int main(void)
{
int i, * data;
data = malloc(sizeof(int) * 100);
if(data) {
for(i = 0; i < 100; i++) {
data = i'
}
}
/* free(data) ? */
return 0;
}
 
S

Shao Miller

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

Example:
int main(void)
{
int i, * data;
data = malloc(sizeof(int) * 100);
if(data) {
for(i = 0; i < 100; i++) {
data = i'
}
}
/* free(data) ? */
return 0;
}


I've seen arguments for:
- Program performance
- Program size

And against:
- Programmer habit
- Cases where program termination doesn't free memory allocated by the
program

I think it's a worth-while habit to 'free' them, in general.
 
N

Nobody

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

No.

In complex programs where freeing data may be mixed with other clean-up,
I may set __free_hook to an empty function when termination is imminent.
 
S

Shao Miller

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the
space up?

Example:
int main(void)
{
int i, * data;
data = malloc(sizeof(int) * 100);
if(data) {
for(i = 0; i < 100; i++) {
data = i'
}
}
/* free(data) ? */
return 0;
}


I've seen arguments for:
- Program performance
- Program size

And against:
- Programmer habit
- Cases where program termination doesn't free memory allocated by the
program

I think it's a worth-while habit to 'free' them, in general.


Uh, I meant "for not bothering" and "against not bothering." :)
 
B

Ben Pfaff

Billy Mays said:
In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the
space up?

One reason that I sometimes bother is that it's very clear that a
program that frees all of its memory does not have a memory leak
(when I use a tool that reports memory statistics at program
exit).
 
I

Ian Collins

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

Code fragments that will never be reused often are, so get into good
habits early!
 
M

Martin Ambuhl

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

You should always free any space you have allocated. There is no
guarantee that the OS will do it for you. Even if the OS you are
currently using claims it will do so, relying on such behavior makes
your code non-portable and there is no warrant in the C standard for
expecting otherwise (since the C standard can hardly decree such this
for the OS).

No example is needed.
 
M

Martin Ambuhl

No.

In complex programs where freeing data may be mixed with other clean-up,
I may set __free_hook to an empty function when termination is imminent.

It is appropriate that this incorrect answer came from "Nobody".
 
J

James Kuyper

In the case where you know that your program will be terminating after
it is done using the pointers, should you even bother freeing the space up?

Example:
int main(void)
{
int i, * data;
data = malloc(sizeof(int) * 100);
if(data) {
for(i = 0; i < 100; i++) {
data = i'
}
}
/* free(data) ? */
return 0;
}


It's not necessary, but I think it's easier to not make a special case
of main(); the rules for creating well-written code are easier to
remember if they don't have more special cases than they have to.

Also, there's always the possibility that code from main() may someday
get moved off to another function; if that code already contains
properly connected malloc() and free() calls, that's one less thing to
worry about during the move.
 
N

Nobody

It's not necessary, but I think it's easier to not make a special case
of main(); the rules for creating well-written code are easier to
remember if they don't have more special cases than they have to.

Sometimes, explicitly freeing memory requires added complexity in order
to keep track of what needs to be freed. E.g. if you have linked data
structures where you could have multiple pointers to a single block of
memory, you have to take steps to avoid multiple free()s of a single
block. Similarly if pointers can be to either static or dynamic data.

Adding such complexity is especially pointless if it only comes into play
upon termination, e.g. if you have complex structures which must exist in
order for the program to perform its normal function.
Also, there's always the possibility that code from main() may someday
get moved off to another function; if that code already contains
properly connected malloc() and free() calls, that's one less thing to
worry about during the move.

If the structure of the code is such that "pairing" malloc and free makes
sense, I'll do it. But in that case, I may set __free_hook (glibc) or
similar to point to an empty function once termination is assured. This
also deals with external libraries which typically have to free()
everything upon finalisation to be on the safe side.

Meticulously free()ing memory when you know that the program is about to
terminate is like rearranging the deckchairs as the Titanic is sinking.
Such operations can often take far longer than is immediately apparent, as
you often end up walking through memory which has long since been swapped
out.
 
E

Edward A. Falk

And against:
- Programmer habit
- Cases where program termination doesn't free memory allocated by the
program

- Chances that your code will be re-purposed into some larger
program that *won't* terminate any time soon and which will call
your code repeatedly.
 
G

Geoff

I'm afraid I've missed whatever point you're making.

I think it means it was once a frequently answered question, now it's
in the FAQ so it no longer needs to be frequently answered. People can
read the FAQ and don't need to ask it in the group. Either that, or he
thinks the FAQ doesn't answer the question but FAQ stands for
Frequently Asked Questions, without answers.
 
K

Keith Thompson

James Kuyper said:
I presume that he's commenting on the difference between "Asked" and
"Answered".

I must admit I didn't notice that he changed the word from "asked" to
"answered".

Now that I've noticed, I'm not sure I've ever seen FAQ expanded
to "Frequently Answered Questions" rather than "Frequently Asked
Questions", and I still have no idea what Michael is getting at.
Is he suggesting that Eric should have done something other than
cite the FAQ?

Sorry if I'm being dense.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top