Unless you are forced to use C, you should never use malloc
. Always use new
.
If you need a big chunk of data just do something like:
char *pBuffer = new char[1024];
Be careful though this is not correct:
//This is incorrect - may delete only one element, may corrupt the heap, or worse...
delete pBuffer;
Instead you should do this when deleting an array of data:
//This deletes all items in the array
delete[] pBuffer;
The new
keyword is the C++ way of doing it, and it will ensure that your type will have its constructor called. The new
keyword is also more type-safe whereas malloc
is not type-safe at all.
The only way I could think that would be beneficial to use malloc
would be if you needed to change the size of your buffer of data. The new
keyword does not have an analogous way like realloc
. The realloc
function might be able to extend the size of a chunk of memory for you more efficiently.
It is worth mentioning that you cannot mix new
/free
and malloc
/delete
.
Note: Some answers in this question are invalid.
int* p_scalar = new int(5); // Does not create 5 elements, but initializes to 5
int* p_array = new int[5]; // Creates 5 elements
Just about every modern operating system will recover all the allocated memory space after a program exits. The only exception I can think of might be something like Palm OS where the program's static storage and runtime memory are pretty much the same thing, so not freeing might cause the program to take up more storage. (I'm only speculating here.)
So generally, there's no harm in it, except the runtime cost of having more storage than you need. Certainly in the example you give, you want to keep the memory for a variable that might be used until it's cleared.
However, it's considered good style to free memory as soon as you don't need it any more, and to free anything you still have around on program exit. It's more of an exercise in knowing what memory you're using, and thinking about whether you still need it. If you don't keep track, you might have memory leaks.
On the other hand, the similar admonition to close your files on exit has a much more concrete result - if you don't, the data you wrote to them might not get flushed, or if they're a temp file, they might not get deleted when you're done. Also, database handles should have their transactions committed and then closed when you're done with them. Similarly, if you're using an object oriented language like C++ or Objective C, not freeing an object when you're done with it will mean the destructor will never get called, and any resources the class is responsible might not get cleaned up.
Best Solution
You have a few options:
GLIBC-specific solution (mostly Linux). If your compilation environment is
glibc
withgcc
, the preferred way is to use malloc hooks. Not only it lets you specify custommalloc
andfree
, but will also identify the caller by the return address on the stack.POSIX-specific solution. Define
malloc
andfree
as wrappers to the original allocation routines in your executable, which will "override" the version from libc. Inside the wrapper you can call into the originalmalloc
implementation, which you can look up usingdlsym
withRTLD_NEXT
handle. Your application or library that defines wrapper functions needs to link with-ldl
.Linux specific. You can override functions from dynamic libraries non-invasively by specifying them in the
LD_PRELOAD
environment variable.Mac OSX specific.
Same as Linux, except you will be using
DYLD_INSERT_LIBRARIES
environment variable.