[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Should you free your pointers?

Carl

6/24/2011 8:41:00 PM

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] = i'
}
}
/* free(data) ? */
return 0;
}

--
Bill
41 Answers

Shao Miller

6/24/2011 8:51:00 PM

0

On 6/24/2011 16:41, Billy Mays wrote:
> 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] = 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.

John Doe

6/24/2011 8:54:00 PM

0

On Fri, 24 Jun 2011 16:41:00 -0400, Billy Mays wrote:

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

Shao Miller

6/24/2011 8:56:00 PM

0

On 6/24/2011 16:51, Shao Miller wrote:
> On 6/24/2011 16:41, Billy Mays wrote:
>> 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] = 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." :)

Ben Pfaff

6/24/2011 9:06:00 PM

0

Billy Mays <noway@nohow.com> writes:

> 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).
--
Ben Pfaff
http://be...

Ian Collins

6/24/2011 9:32:00 PM

0

On 06/25/11 08:41 AM, Billy Mays wrote:
> 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!

--
Ian Collins

Martin Ambuhl

6/24/2011 11:05:00 PM

0

On 6/24/2011 4:41 PM, Billy Mays wrote:
> 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).

> Example:

No example is needed.

Martin Ambuhl

6/24/2011 11:06:00 PM

0

On 6/24/2011 4:53 PM, Nobody wrote:
> On Fri, 24 Jun 2011 16:41:00 -0400, Billy Mays wrote:
>
>> 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.
>

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

Eric Sosman

6/25/2011 1:19:00 AM

0

On 6/24/2011 4:41 PM, Billy Mays wrote:
> 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?

This is Question 7.24 on the comp.lang.c Frequently Asked
Questions (FAQ) page at <http://www.c-fa....

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

James Kuyper

6/25/2011 2:08:00 AM

0

On 06/24/2011 04:41 PM, Billy Mays wrote:
> 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] = 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.
--
James Kuyper

John Doe

6/25/2011 2:28:00 PM

0

On Fri, 24 Jun 2011 22:07:46 -0400, James Kuyper wrote:

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

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