Ignoring programming style and design, is it “safe” to call delete on a variable allocated on the stack?
For example:
int nAmount;
delete &nAmount;
or
class sample
{
public:
sample();
~sample() { delete &nAmount;}
int nAmount;
}
Ignoring programming style and design, is it “safe” to call delete on a variable allocated on the stack?
For example:
int nAmount;
delete &nAmount;
or
class sample
{
public:
sample();
~sample() { delete &nAmount;}
int nAmount;
}
Related: stackoverflow.com/questions/434140/…
Note that your second example doesn't have to be on the stack. nAmount would be local to whatever memory sample exists in.
About as safe as poking a sharp needle in your eye.
nasal demons – this is what happens
One kitten gets killed somewhere.
No, it is not safe to call
deleteon a stack-allocated variable. You should only calldeleteon things created bynew.mallocorcalloc, there should be exactly onefree.newthere should be exactly onedelete.new[]there should be exactly onedelete[].In general, you cannot mix and match any of these, e.g. no
free-ing ordelete[]-ing anewobject. Doing so results in undefined behavior.Well, let’s try it:
So apparently it is not safe at all.
Keep in mind that when you allocate a block of memory using new (or malloc for that matter), the actual block of memory allocated will be larger than what you asked for.
The memory block will also contain some bookkeeping information so that when you free the block, it can easily be put back into the free pool and possibly be coalesced with adjacent free blocks.
When you try to free any memory that you didn’t receive from new, that bookkeeping information wont be there but the system will act like it is and the results are going to be unpredictable (usually bad).
No,
Memory allocated using new should be deleted using delete operator
and that allocated using malloc should be deleted using free.
And no need to deallocate the variable which are allocated on stack.
here the memory is allocated using stack so no need to delete it exernally but if you have allcoted dynamically
like
int *a=new int()
then you have to do delete a and not delete &a(a itself is a pointer), because the memory is allocated from free store.
After playing a bit with g++ 4.4 in windows, I got very interesting results:
calling delete on a stack variable doesn’t seem to do anything. No errors throw, but I can access the variable without problems after deletion.
Having a class with a method with
delete thissuccessfully deletes the object if it is allocated in the heap, but not if it is allocated in the stack (if it is in the stack, nothing happens).Nobody can know what happens. This invokes undefined behavior, so literally anything can happen. Don’t do this.
An angel loses its wings… You can only call
deleteon a pointer allocated withnew, otherwise you get undefined behavior.Yes, it is undefined behavior: passing to
deleteanything that did not come fromnewis UB:The consequences of undefined behavior are, well, undefined. “Nothing happens” is as valid a consequence as anything else. However, it’s usually “nothing happens right away”: deallocating an invalid memory block may have severe consequences in subsequent calls to the allocator.
You already answered the question yourself.
deletemust only be used for pointers optained throughnew. Doing anything else is plain and simple undefined behaviour.Therefore there is really no saying what happens, anything from the code working fine through crashing to erasing your harddrive is a valid outcome of doing this. So please never do this.
It’s UB because you must not call delete on an item that has not been dynamically allocated with new. It’s that simple.