Call delete on a variable allocated on the stack

Question

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; } 

Answer 1

No , it is not safe to call delete on a variable assigned by the stack. You should only call delete for objects created by new .

• There must be exactly one free for each malloc or calloc .
• For each new must be exactly one delete .
• For each new[] must be exactly one delete[] .
• There should be no explicit release or deletion for each stack allocation. The destructor is called automatically, where applicable.

In general, you cannot mix and match any of them, for example. no free -ing or delete[] -ing a new object. This leads to undefined behavior.

Answer 2

Well, try:

 jeremy@jeremy-desktop:~$ echo 'main() { int a; delete &a; }' > test.cpp jeremy@jeremy-desktop:~$ g++ -o test test.cpp jeremy@jeremy-desktop:~$ ./test Segmentation fault 

Therefore, it is obvious that it is not safe.

Answer 3

Keep in mind that when you allocate a memory block using a new one (or malloc, for that matter), the actual allocated memory block will be larger than what you requested. The memory block will also contain some accounting information, so that when you free the block, it can be easily returned back to the free pool and possibly combined with adjacent free blocks.

When you try to free up any memory that you have not received from the new one, this accounting information will not be there, but the system will act as it is, and the results will be unpredictable (usually bad). A.

Answer 4

Yes, this behavior is undefined: switching to delete all that did not come from new is UB:

C ++ Standard, section 3.7.3.2.3: The value of the first argument provided by one of the maladaptation functions provided in the standard library may be a null pointer value; if so, and if the release function is included in the standard library, the call to the release function is not affected. Otherwise, the value specified in operator delete(void*) in the standard library must be one of the values ​​returned by the previous call either operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&) in the standard library.

The consequences of undefined behavior are, well, undefined. “Nothing happens” is not as important a consequence as anything else. However, usually “nothing happens immediately”: the release of an invalid memory block can have serious consequences on subsequent allocator calls.

Answer 5

After playing a bit with g ++ 4.4 on windows, I got very interesting results:

• calling delete on the stack variable does not seem to do anything. There are no errors, but I can access the variable without problems after deletion.

• Having a class with the delete this method successfully deletes the object if it is allocated on the heap, but not if it is allocated on the stack (if it is on the stack, nothing happens).

Answer 6

No one knows what is going on. This causes undefined behavior, so literally anything can happen. Do not do this.

Answer 7

No, the memory allocated using the new one must be deleted using the delete operator and that the allocated use of malloc should be deleted using the free one. And there is no need to free a variable that is allocated on the stack.

Answer 8

An angel loses its wings ... You can only call delete pointer highlighted with new , otherwise you will get undefined behavior.

Answer 9

here the memory is allocated using the stack, so there is no need to delete it differently, but if you dynamically specified

like int * a = new int ()

then you need to delete a, not delete & a (the pointer itself), as the memory is allocated from free storage.

Answer 10

You yourself have answered the question. delete should be used only for pointers preceded by new . Doing the rest is simple and simple undefined behavior.

Thus, in fact, there are no statements about what is happening, something from the code that is working normally, through a failure, to erase your hard drive, is the correct result of this. Therefore, never do this.

Answer 11

This is UB because you should not call delete on an element that has not been dynamically allocated by the new one. It's simple.