Creating a pointer and asigning a variable address to it
-
When you both create a pointer and allocate memory (with “new”) that the pointer will point to, it’s almost like creating an invisible variable. When you want to dispose if you delete the pointer the case is solved. However if you declare a variable and assign the variable address to a pointer, later if you use “delete” on the pointer will that delete the content of the variable too?
-
When you both create a pointer and allocate memory (with “new”) that the pointer will point to, it’s almost like creating an invisible variable. When you want to dispose if you delete the pointer the case is solved. However if you declare a variable and assign the variable address to a pointer, later if you use “delete” on the pointer will that delete the content of the variable too?
If you're responsible for managing memory you've allocated, then freeing it means it's gone; regardless of which part of your app did it. i.e. you're the one "counting the references".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
When you both create a pointer and allocate memory (with “new”) that the pointer will point to, it’s almost like creating an invisible variable. When you want to dispose if you delete the pointer the case is solved. However if you declare a variable and assign the variable address to a pointer, later if you use “delete” on the pointer will that delete the content of the variable too?
It is "undefined behaviour": so it could result in segmentation fault or it could behave like this delete would be ignored. Or something else. See the discussion [https://stackoverflow.com/questions/441831/calling-delete-on-variable-allocated-on-the-stack\](https://stackoverflow.com/questions/441831/calling-delete-on-variable-allocated-on-the-stack)
-
When you both create a pointer and allocate memory (with “new”) that the pointer will point to, it’s almost like creating an invisible variable. When you want to dispose if you delete the pointer the case is solved. However if you declare a variable and assign the variable address to a pointer, later if you use “delete” on the pointer will that delete the content of the variable too?
In case 1 you are creating a
newblock of dynamic memory space. When you calldeleteon the pointer it returns the memory space to the free pool, but the pointer still exists (until it goes out of scope, or the program ends). In case 2 the pointer is referring to memory space that already exists, i.e. it was not created bynew, so you cannot calldeleteon it. -
When you both create a pointer and allocate memory (with “new”) that the pointer will point to, it’s almost like creating an invisible variable. When you want to dispose if you delete the pointer the case is solved. However if you declare a variable and assign the variable address to a pointer, later if you use “delete” on the pointer will that delete the content of the variable too?
The purpose of `delete` is not to delete things. What?? But I'm serious. The purpose of `delete` is to undo `new`. As an approximation that will no doubt anger several C++ experts, you can view `new` as a combination of `malloc` and invoking the constructor, and you can view `delete` as a combination of invoking the destructor and `free`. That's not exactly literally how they work, but it's close enough that you can use that to reason about when you need them. (don't use this as an excuse to `delete` something that was `malloc`'ed) Most of the time, if you want to get rid of something, `delete` is the wrong way to do it - because most things were not created by `new`. Trying to `delete` something else results *at best* in a failing safety check but in general corrupts the state of your application. Most objects are destroyed implicitly, in various ways. Local variables by exiting a scope, values in containers by the container being destroyed, smart pointers do most of the rest. Explicitly using `delete` is occasionally necessary but it's probably better to actively avoid creating those cases. It's quite bug-prone, especially around exceptions and other non-trivial control flow.
Calin Negru wrote:
later if you use “delete” on the pointer will that delete the content of the variable too?
In the sense that its destructor is invoked (so you can implement it and `delete` the members that need to be deleted), yes. If you mean that in some other sense then, probably, no (but depending on what you mean). Implementing classes with lots of raw-pointer members that you individually `delete` in the destructor is very mid-2000s. Typical advice is to delegate that to smart pointers and containers as much as possible, with the goal of following the Rule of Zero instead of one of the other rules-of-some-number, but sometimes you just have to do what you have to do.
-
In case 1 you are creating a
newblock of dynamic memory space. When you calldeleteon the pointer it returns the memory space to the free pool, but the pointer still exists (until it goes out of scope, or the program ends). In case 2 the pointer is referring to memory space that already exists, i.e. it was not created bynew, so you cannot calldeleteon it.Thank you to everyone for helping
-
The purpose of `delete` is not to delete things. What?? But I'm serious. The purpose of `delete` is to undo `new`. As an approximation that will no doubt anger several C++ experts, you can view `new` as a combination of `malloc` and invoking the constructor, and you can view `delete` as a combination of invoking the destructor and `free`. That's not exactly literally how they work, but it's close enough that you can use that to reason about when you need them. (don't use this as an excuse to `delete` something that was `malloc`'ed) Most of the time, if you want to get rid of something, `delete` is the wrong way to do it - because most things were not created by `new`. Trying to `delete` something else results *at best* in a failing safety check but in general corrupts the state of your application. Most objects are destroyed implicitly, in various ways. Local variables by exiting a scope, values in containers by the container being destroyed, smart pointers do most of the rest. Explicitly using `delete` is occasionally necessary but it's probably better to actively avoid creating those cases. It's quite bug-prone, especially around exceptions and other non-trivial control flow.
Calin Negru wrote:
later if you use “delete” on the pointer will that delete the content of the variable too?
In the sense that its destructor is invoked (so you can implement it and `delete` the members that need to be deleted), yes. If you mean that in some other sense then, probably, no (but depending on what you mean). Implementing classes with lots of raw-pointer members that you individually `delete` in the destructor is very mid-2000s. Typical advice is to delegate that to smart pointers and containers as much as possible, with the goal of following the Rule of Zero instead of one of the other rules-of-some-number, but sometimes you just have to do what you have to do.
