New/Delete...New[]/Delete[]
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
New/Delete...New[]/Delete[]
Just going to sneak this in here.
There are a number of ways to accomplish the same, here's but one. To be honest, this is the first homework assignment I've completed here on the forums after 4+ years of following chili.
Spoiler:
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: New/Delete...New[]/Delete[]
Cool! You did it different (most likely better) than i did.
Thanks for sharing!
Thanks for sharing!
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: New/Delete...New[]/Delete[]
Oh, btw, I don't think chili mentioned this in the video, but when you delete/delete[] a pointer using new/new[] it's good practice to set that deleted pointer to nullptr. This way if you do try to use it again, say: if(pointer != nullptr) or assert( pointer != nullptr ) you'll be able to tell there is something wrong. If you don't set to nullptr and try the above then you'll end up getting unexpected results.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: New/Delete...New[]/Delete[]
Yeah, not sure if I mentioned that in the video either. I definitely mention it in the homework solution video though.
You might be interested in the T6 homework as well. Gonna structure it (have already structured it) like a coding challenge with a bunch of test cases and stuff like that.
You might be interested in the T6 homework as well. Gonna structure it (have already structured it) like a coding challenge with a bunch of test cases and stuff like that.
Chili
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: New/Delete...New[]/Delete[]
Sweet, looking forward to it...
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: New/Delete...New[]/Delete[]
I finished the HW for T5 too... I was really lazy so I tried to make the least amount of changes needed to finish the HW.
In case anyone is interested here is my take on the HW: GitHub
I was aware of the nullptr thingy, but I didn't set my pointers to nullptr because I don't think it's needed in my case. (But if that's bad practice then pls tell me thx)
In case anyone is interested here is my take on the HW: GitHub
I was aware of the nullptr thingy, but I didn't set my pointers to nullptr because I don't think it's needed in my case. (But if that's bad practice then pls tell me thx)
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: New/Delete...New[]/Delete[]
It is bad practice to not set to nullptr, but then again, if you are never testing for nullptr and just replacing the pointer, then setting to nullptr would be a waste of your time anyway.
It would be wise to check for a valid pointer before deleting. If nullptr, then don't delete, but if you don't set to nullptr when deleting, then there's a chance that you will delete a pointer that has already been deleted and crash your app.
In this particular situation, you are correct in stating that the safety checks aren't really needed. I couldn't find a way for things to go wrong, but as programs get bigger, it's always a good idea to play it safe and either use smart pointers ( unique_ptr or shared_ptr ) or check for a valid pointer before delete and set to nullptr after delete.
It would be wise to check for a valid pointer before deleting. If nullptr, then don't delete, but if you don't set to nullptr when deleting, then there's a chance that you will delete a pointer that has already been deleted and crash your app.
In this particular situation, you are correct in stating that the safety checks aren't really needed. I couldn't find a way for things to go wrong, but as programs get bigger, it's always a good idea to play it safe and either use smart pointers ( unique_ptr or shared_ptr ) or check for a valid pointer before delete and set to nullptr after delete.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: New/Delete...New[]/Delete[]
Oh okay. You cleared up some things for me
I will definitely do as you say if I were to use raw pointers in my projects in the future.
Thanks for the reply albinopapa
I will definitely do as you say if I were to use raw pointers in my projects in the future.
Thanks for the reply albinopapa
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: New/Delete...New[]/Delete[]
Checking for null has been a way for programmers to check for the existence of a valid pointer for maybe a couple of reasons. One reason would be to make sure they aren't freeing/deleting memory that has already been freed/deleted or hasn't been allocated yet. Another would be getting a pointer back from a library function. In some cases, if the parameters to the function were invalid, or an object from a list wasn't found, a nullptr was returned. Another would be to prevent memory leaks. If you are reusing a pointer variable and it is not set to nullptr then it should be deallocated before reusing it. In this instance, if allocating directly after deallocating, the obviously setting to nullptr isn't necessary. Same would hold true for local pointers. If you allocate a pointer inside a function, you must deallocate before the function ends to avoid memory leaks, but the variable is lost and can't be reused so there is no need to set to nullptr.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: New/Delete...New[]/Delete[]
Actually, you might be interested to learn that NOT checking a pointer before calling delete is standard practice, and checking for nullptr is redundant. The delete operator is guaranteed to have no effect in the case where the pointer value is equal to nullptr.albinopapa wrote:It would be wise to check for a valid pointer before deleting. If nullptr, then don't delete, but if you don't set to nullptr when deleting, then there's a chance that you will delete a pointer that has already been deleted and crash your app.
It might be okay though to do an assertion check for nullptr, if trying to delete null is a nonsensical code path for your routine. Also, if for some reason you override delete and change its behavior to not ignore null (seems pretty dumb), then you would have to do the check ofc.
Chili