Do I need to reset the pointer after using the operator delete ? Or does it, unlike the malloc function, reset the pointer itself?
int *v = new int(5); delete v; v = nullptr; And what about deleting the pointer in the following code:
(1) int *a = new int[10]; (2) delete [] a; (3) delete a; (4) a = nullptr; Do I need to delete the pointer, as in the third line? If not, then I understand that it is necessary to reset it, as in the fourth?
This code has an undefined behavior, as there is an attempt to double-delete the memory addressed by the pointer a , and the wrong delete statement is used a second time.
int *a = new int[10]; delete [] a; delete a; a = nullptr; It is usually advised to reset the pointer after releasing the memory indicated by it, so that when you try to delete the memory again, you will not get a program execution error. For example, this code is correct.
int *a = new int[10]; //... delete [] a; a = nullptr; //... delete [] a; since you can call the operators delete and delete[] for null pointers.
However, by doing so you mask a potential error in your program. It is possible that your program is malfunctioning and, indeed, is trying to at least twice delete the same area of memory. If you assign a nullptr value to the pointer, then it will be difficult for you to detect this error.
The argument for assigning a value to nullptr is that if you have a pointer equal to nullptr , then it will be easy for you to detect an attempt to access memory using that pointer. However, in reality this is not always the case. For example, the z/OS operating system on IBM mainframe allows you to read memory using a null pointer. It only does not allow to write data on such a pointer. Therefore, again, by assigning a nullptr value nullptr pointer, you can disguise the error when you access the readable memory at the zero address. In my experience, such a mistake is often made by C programmers working on the IBM mainfarme when using standard string functions from the <string.h> library, calling, for example, the string comparison function strcmp , when one of the pointers is NULL . As a result, the program has an undefined behavior. But to detect such an error is very difficult.
On the other hand, explicitly assigning a nullptr value to the nullptr facilitates self-documenting of the source code. The reader is given to know that, starting with this assignment, the pointer is invalid.
So there is no universal rule. It is advisable to make it so that the lifetime of the variable designating the pointer matches the lifetime of the memory it points to. In this case, there is no point in assigning a nullptr value to the nullptr , since the pointer ceases to exist at the same time as the memory addressed by it is deleted.
Most often, you can come across a code where either initialization of the pointer by zero is used, or assignment to it null values in old C programs, since previously, before adopting the C99 standard, variables could be declared only at the beginning of the code blocks. Therefore, between the declaration of the pointer and its use or between the removal of the memory addressed by the pointer and the termination of the pointer itself, there are often many lines of code that are difficult to cover with one look at the source text. Therefore, assigning null values to pointers allowed the code reader to more easily understand the logic of this or that cumbersome function.
Currently, both in C and in C ++, you can declare variables anywhere in a code block, and therefore you can narrow the lifetime of variables to the part of the code where they are directly used. Therefore, there is no longer any need to assign a null value to the "spent" pointer.
Try to declare variables in the smallest declaration area where they are directly used. so that there are no "pending" variables that cannot be said about whether they are used elsewhere in the code, or whether they are no longer used.
In addition, in C ++ there are so-called smart pointers, as well as corresponding containers that themselves take care of deleting the memory that is no longer in use. The allocation and deletion of memory "manually" is fraught with errors in the program.
Let's distinguish between a pointer and the data it points to.
The delete operator works with the memory pointed to by the pointer. Moreover, if you allocated memory with new , then you need to free with delete . And if with the help of new[...] , then you need to free with the help of delete[] . (The responsibility for this lies with you.)
The delete operator does not change the pointer, but after delete points to invalid memory (most likely, this memory will be allocated to someone else for its purpose). It makes sense to independently assign the value of nullptr pointer after delete , so as not to accidentally use invalid memory. But this is not necessarily and rather a precaution for you, rather than a language requirement.
There is only one requirement for the language: after delete you should not access the allocated memory system by pointer. How you ensure this is all your concern.
Yes, and the second time you can not delete the object by the pointer! Because it is generally impossible to access the remote memory (an attempt to delete is also an appeal). Therefore, line (3) incorrect on both sides: this is the repeated deletion of memory, which is prohibited, and deletion without [] , although the memory was allocated with [] .
With the pointer, you can do whatever you want :) delete doing nothing on the variable itself. You can reset it, you can - no, but then just remember that it now indicates where it is not clear, and this value can no longer be used.
In your example, delete correctly as in line 2.
(In a whisper: for int , though, due to the lack of destructors, the third method will come down ... but in general, this is a mistake! In a whisper, so that no one takes it as permission to do this :) I just mentioned it, but I insist on not to do so in any way! )
Line 4 is up to you ...
delete simply frees the memory. Theoretically, new[] and new are different operations, so delete , where you need delete[] , can lead to problems ... but so far I have not heard of a compiler that would really lead to them for fundamental types. However, in any case, personally, I categorically do not recommend doing so ... Now I will strengthen this moment in the answer :) - Harrymalloc / free , which are not able to distinguish one element from the set, therefore, in practice, the memory should be freed correctly. This does not negate the fact that such application itself is UB. - ixScidelete[] simply causes delete . There are no other sources, but I showed the test drive on VC ++ ... - HarryThis is what is written in the smart book .. When the delete operator is applied to a pointer, the area of dynamic memory that it points to is released. Re-applying the delete operator to the same pointer will cause the program to hang. When releasing the dynamic memory area, it is recommended that the pointer associated with it be set to zero (0). Calling the delete operator for the null pointer will be completely painless for the program. Example:
Animal *pDog = new Animal; delete pDog; // освобождение динамической памяти pDog = 0; // присвоение указателю нулевого значения delete pDog; // вполне безопасно ps book on the standard 98 years.
Source: https://ru.stackoverflow.com/questions/596450/
All Articles