tags:

views:

183

answers:

6

Is there a one-liner that will free the memory that is being taken by all pointers you created using mallocs? Or can this only be done manually by freeing every pointer separately?

+2  A: 

malloc on it's own has implementation-defined behavior. So there isn't a necessity for it to keep track of all the pointers it has, which obviously puts a damper on the idea.

You'd need to make your own memory manager that tracks the pointers, and then provides a function called free_all or something that goes through the list of pointers it has and calls free on them.

Note, this sounds like a somewhat bad idea. It's better to be a bit more strict/responsible about your memory usage, and free things when you're done; not leave them hanging about.

Perhaps with a bit more background on where you want to apply your idea, we might find easier solutions.

GMan
AND THAT IS WHAT I SAID -.-'''' yes i could also include half a book in my answer but i personally like comments that are short and informative not loads of trash with 2 usefull informations . kthxbye
n00b32
Half a book? I wish I had the patience to write half a book. "No, and here's why" is much more informative than "No". Also, if you want to get up in arms about it, *at least mine is readable*. :o
GMan
@n00b32: Rage-quit is only allowed here if you actually quit. Save the tantrums for elsewhere.
Roger Pate
"here is why" ? on it's own has implementation-defined behavior <-- everything has . Note, this sounds like [...] hanging about. you do not know if they are. maybe he needs it for a purpose ? You'd need to make [...] free on them. thats what i said but with 20x more words . i dont care how many downvotes i get. ill say what i think. my is also readable if it is not get rid of those cultural blocks youve created in your mind ;) @roger: do so. please. EOD (End Of Discussion) on my side. (It means i will no longer continue to respond to your rants .)
n00b32
"Implementation-defined behavior" has a specific meaning from the language standard, it is not some vague term.
Roger Pate
@n00b32: There's no cultural roadblock, people just don't enjoy bad grammar and spelling. You misunderstand what I mean by readable. I don't mean it's *possible* to read: is't eays ot swho poelpe cna rdae rlelay mdeses pu stfuf. What it means is it's *easy* to read. And good English is easier to read, for English readers, than bad English. That's all; I'm not trying to attack you, nobody wants to start some flame war.
GMan
+3  A: 

you could do that by creating some kind of "wrapper" around malloc. (warning that's only pseudo code showing the idea, there is no checking at all)

void* your_malloc(size_t size)
{
    void* ptr = malloc(size);

    // add ptr to a list of allocated ptrs here

    return ptr;
}

void your_free(void *pointer)
{
    for each pointer in your list
    {
        free( ptr_in_your_list );
    }
}

But it doesn't sound like a good idea and I would certainly not do that, at least for general purpose allocation / deallocation. You'd better allocate and free memory responsibly when it is no longer needed.

f4
A: 

No, you can't. There are various ways to sort-of accomplish this, but some of them encourage sloppy habits (for example, most runtimes on most OSs will release all the memory you allocated when your process exists, but this won't help you during the execution of your program and usually won't release shared resources that are not core memory).

One viable method is to use a pool allocator -- there are plenty of resources on the topic if you ask Google about it. The concept is rather simple: you allocate (with malloc) one large pool of memory yourself at some start time, and then you manually suballocate (with your own hand-rolled function) from that pool, just returning pointers to blocks of the appropriate size that you keep track of yourself. Then you can free everything with one call to free that matches the original malloc call.

However, the reason to do this isn't so that you can be lazy with your memory handling: you do this because of some performance-related reasons, usually, like providing superior locality of reference of small allocations or some such. If you want to do this just because you don't want to think about remembering to release the resources you allocate, well... that's not so great.

Other languages provide mechanisms (such as built-in garbage collectors, like C#, or RAII, like C++). But in C you generally need to be aware of your memory usage and manage it yourself, because there are fewer mechanisms to automate the cleanup for you.

Josh Petrie
A: 

You might want to do something called "arena allocation", where you allocate certain requests from a common "arena" which can be freed all at once when you're done.

If you're on Windows, you can use HeapCreate to create an arena, HeapAlloc to get memory from the heap/arena you just created, and HeapDestroy to free it all at once.

Note that when your program exit()s, all the memory you allocated with malloc() is freed.

Andrew
A: 

Yes, you can do that unless you write your own defintion of malloc() and free(). You should probably call myCustomMalloc() instead of regular malloc() and you should be keeping track of all the pointers in some memory location and when you call the myCustomFree() method, you should be able to clear all the pointers that was created using your myCustomMalloc(). Note: both your custom methods will be calling malloc() and free() internally

By this way you can achieve your goal. I am a java person but I use to work a lot in C in my early days. I assume that you're trying to achieve a common solution where memory is being handled by the compiler. That has a cost of performance as it is seen in Java. You dont have to worry about allocation and freeing the memory. But that has a severe effect on performance. Its a tradeoff that you have to live with.

Bragboy
+3  A: 

You might want to look into memory pools. These are data structures built to do exactly this.

One common implementation is in the Apache Portable Runtime, which is used in the Apache web server, as well as other projects, such as Subversion.

Avi