Why NOT use new with free?
I have been to an C++ interview recently and they asked me the question - "Can we use free keyword to free the new'ed memory?" I said, "We can. It is technically feasible but NOT advisable." I also said some of the below points:
1. new'ed memory is allocated on the heap where as malloc is on stack
2. new'ed memory should always be deleted where as malloc'ed memory should always be freed.
3. new/delete calls the class' ctor and dtor where as malloc/free does not.
The interviewer was still not satisfied with my answers I think and that is why he asked, "All these are OK but can you say WHY should you not use free and new together?" I said, "we should not because it is not the best practice and free'ing a new'ed memory could cause undefined/unexpected behaviors."
I think he still was not satisfied. He asked, "What is the problem if free does not call the dtor? can we not use free(obj); and then manually call the dtor?"
I had no answer to this... Can anybody give me proper technical (internal/in-depth) explanation of why should we not free a new'ed memory, please?
1. new'ed memory is allocated on the heap where as malloc is on stack
2. new'ed memory should always be deleted where as malloc'ed memory should always be freed.
3. new/delete calls the class' ctor and dtor where as malloc/free does not.
The interviewer was still not satisfied with my answers I think and that is why he asked, "All these are OK but can you say WHY should you not use free and new together?" I said, "we should not because it is not the best practice and free'ing a new'ed memory could cause undefined/unexpected behaviors."
I think he still was not satisfied. He asked, "What is the problem if free does not call the dtor? can we not use free(obj); and then manually call the dtor?"
I had no answer to this... Can anybody give me proper technical (internal/in-depth) explanation of why should we not free a new'ed memory, please?
Well, calling free on a new'ed block is undefined behaviour. That's correct. And this is the reason why you should never ever do this! Not because "it's not so nice, but if you have to..." - NO! DON'T!
Most of the time, it will lead to heap corruption, uncalled destructors (as you pointed out) or sudden crashes (segmentation faults). It makes the code unpredictable (you never know whether it will run a second time. It may pass the tests, but blow up later etc..). It may run in Debug mode but not in Release mode (because optimizations shift stuff around). "Undefined behaviour" should always be treated as a big "NO".
Said that, there *are* some places where technically something is "undefined behaviour" but gets ignored on a regular basis. Most famous is the Win32 API and it's MESSAGE - stuct, where you have only two integer values LPARAM and WPARAM for a message. Most people don't think twice when casting these values between integer and pointer back and forth, although it's technically undefined behaviour.
But calling delete on a malloc'ed memory or calling free on a new'ed memory is not one of these!
Another aspect is, that memory allocation could be customized, but in a different way. There is the "operator new" but no "operator malloc" or something like that. On the other hand, some compiler and libraries overwrite the malloc behaviour (by providing an own malloc). Mostly - but not always - for debugging.
By the way.. malloc does not allocate on the stack but on the heap. There is a function that allocates memory on the stack and its called "alloca". It is not standard. Malloc allocates on the heap - same as new. In fact, some compiler just forward new to malloc (in which case you could call free on a new'ed object, if there are no constructors, no destructors, no custom operator new etc.. But it would work only on this compiler and you have to hope that nobody touches anything and the compiler vendor don't decide otherwise blabla..)
About the destructor: There is only one place when you call a destructor directly and that's when you use a technique called "placement new". And that's a very very advanced C++ technique and in general there are lots of comments around those places explaining to younger programmers what's happening and that you should not touch it and even give phone numbers of people to call when you think you want to change something there ;-). (And of course, you would have to call the destructor first and then delete the object. Otherwise you call something on a freed memory. Bad idea!).
Ciao, Imi.
Most of the time, it will lead to heap corruption, uncalled destructors (as you pointed out) or sudden crashes (segmentation faults). It makes the code unpredictable (you never know whether it will run a second time. It may pass the tests, but blow up later etc..). It may run in Debug mode but not in Release mode (because optimizations shift stuff around). "Undefined behaviour" should always be treated as a big "NO".
Said that, there *are* some places where technically something is "undefined behaviour" but gets ignored on a regular basis. Most famous is the Win32 API and it's MESSAGE - stuct, where you have only two integer values LPARAM and WPARAM for a message. Most people don't think twice when casting these values between integer and pointer back and forth, although it's technically undefined behaviour.
But calling delete on a malloc'ed memory or calling free on a new'ed memory is not one of these!
Another aspect is, that memory allocation could be customized, but in a different way. There is the "operator new" but no "operator malloc" or something like that. On the other hand, some compiler and libraries overwrite the malloc behaviour (by providing an own malloc). Mostly - but not always - for debugging.
By the way.. malloc does not allocate on the stack but on the heap. There is a function that allocates memory on the stack and its called "alloca". It is not standard. Malloc allocates on the heap - same as new. In fact, some compiler just forward new to malloc (in which case you could call free on a new'ed object, if there are no constructors, no destructors, no custom operator new etc.. But it would work only on this compiler and you have to hope that nobody touches anything and the compiler vendor don't decide otherwise blabla..)
About the destructor: There is only one place when you call a destructor directly and that's when you use a technique called "placement new". And that's a very very advanced C++ technique and in general there are lots of comments around those places explaining to younger programmers what's happening and that you should not touch it and even give phone numbers of people to call when you think you want to change something there ;-). (And of course, you would have to call the destructor first and then delete the object. Otherwise you call something on a freed memory. Bad idea!).
Ciao, Imi.
Last edited on
Hey Imi,
Thanks a lot for your reply!
All these days... I was thinking that malloc creates memory on stack. Also, your last paragraph is very informative to me.
Thanks a lot for your reply!
All these days... I was thinking that malloc creates memory on stack. Also, your last paragraph is very informative to me.
Topic archived. No new replies allowed.