How to prevent inadvertently using delete and free interchangeably in c++

Question

When, if ever, can delete and free be used interchangeably in C++?

My concern is as follows: Say there is an incorrect mixup in the use of malloc/free and new/delete (not to mention new[]/delete[]). However delete and free doing the same thing fortuitously so this goes uncaught in testing. Later this may lead to a crash in production.

How can I enforce some kind of check to prevent this? Can I be warned if the two are mixed up? If not at compile time, perhaps some code instrumentation at run time? How would I approach this?

Edit: Intention of this question is to find ways to AVOID inadvertent mixup in the usages.

Answer 1

You should always use new and delete in C++, as only new and delete will call the object's constructor and destructor.

If you find you must use both (for instance, if you're interfacing with a C library), thorough code reviews should carefully scrutinize any uses of free() to determine whether or not they correspond to a malloc(), and whether or not they are being used in a C context.

Answer 2

Never. If it works it's by sheer accident of implementation. Do not rely on this behavior.

Answer 3

You should always use delete or delete[] when freeing things allocated with new. The same goes for malloc and free.

If using free for deleting new:ed classes the destructor won't be properly called. Also new and delete doesn't necessarily use malloc/free for its allocations so you might end up corrupting your heap as well.

Answer 4

One thing I've done relating to this is to reimplement malloc and free in C++, so that it calls new/delete under the hood. It's not optimal, but it serves well enough on a smaller project.

Answer 5

The easy way to not get them mixed up is never to use malloc(), then you will never be tempted to call free(). The infrastructure to create to avoid this problem is called "code review", though in this case a quick "grep malloc(" or "grep free(" on the codebase will probably suffice.

Answer 6

always use delete for things allocated with new, delete [] for things allocated with new [] and free() for things allocated using malloc().

new and new[] allocate from different heaps than malloc() and using the wrong free()/delete will attempt to deallocate from the wrong heap.

Answer 7

To answer the second question, if you control both malloc/free and operator new/delete, you can stash extra information to associate with pointers returned by both that tell you how they were allocated. When a pointer is passed to free or operator delete, check to see that it was allocated by the appropriate function. If not, assert or raise an exception or do whatever it is you do to report the mismatch.

Usually this is done by allocating extra memory, e.g., given malloc(size) or operator new(size), you allocate size + additional space and shove extra information in there.

Answer 8

The only way you can ensure you never get them mixed up is by either:

• Never using malloc/free in the first place, or
• Rely on RAII for your memory allocations. Protect every memory allocation in a RAII object which ensures the memory get correctly and consistently freed when it goes out of scope, or wrap the allocation in a smart pointer.

Manually calling delete or free is just an invitation for bugs.

Answer 9

Never mix new/delete with new[]/delete[] or with malloc()/free(). Atop of this, the use of malloc()/free() in C++ is questionable at least.

The easiest way to make sure you never do this accidentally is to not to manage memory manually. In C++ there strings and other containers as well as smart pointers to take care of memory management. There simply isn't a need to do this manually. (I'm not sure whether the last time I remember me typing delete really was the last time I typed it. But if my memory doesn't fail me, this must have been 2001 or 2002.)

Answer 10

You could write your own version of the functions which allocate some extra memory in new/new[]/malloc to track which one did the allocation. Then check in delete/delete[]/free that the right function was used to re-claim the memory. You can also check for things like mixing new[] and delete (without the []) this way. You might want to only use these versions in the debug build.

Answer 11

You could try running valgrind on your application to see if it catches anything. The manual specifically mentions its ability to catch uses of the wrong deallocation function for a block of memory. I don't think there's a way to do this at compile time, however.

Answer 12

Why dont you just count the total number of malloc statments and tally that with the total count of free? Do the same for New and delete. The process can be automated with regular expressions.

Answer 13

If I had to codify it, I'd put in the style guide something like this:

• free() may be called only on a private pointer field of an object.
• malloc()ed buffers (or buffers returned from a C API which caller must free()) must be assigned to a private pointer field of an object.
• private pointer fields which hold free()-able buffers must only be used for that purpose.
• if you use hungarian notation, add a letter for it (and if you don't, don't).
• generally free() will be called only in a destructor, with exceptions when the free()-able buffer is replaced during the lifetime of the object. In that case you can call free() on a value recently copied out of a private field during replacement, rather than on the field value directly.

In other words, stick a wrapper around anything that uses malloc/free. This wrapper could be a single template everyone uses, or you could allow smart pointers with the deletor function set to free(). Then in code review, if you see a call to malloc/free anywhere else, it's wrong.

Basically the best way to stop this being a problem is to be on top of your resource handling in general. In C, people do not have a major problem with accidentally calling free() on streams instead of fclose().