Is there a one-liner that will free the memory that is being taken by all pointers you created using malloc
s? Or can this only be done manually by free
ing every pointer separately?
views:
183answers:
6malloc
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.
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.
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.
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.
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.
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.