New/Delete...New[]/Delete[]

The Partridge Family were neither partridges nor a family. Discuss.
albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

New/Delete...New[]/Delete[]

Post by albinopapa » June 29th, 2017, 3:41 am

Just going to sneak this in here.
Spoiler:
It's my I5 homework. MemeSweeper Homework
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.
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

User avatar
Yumtard
Posts: 575
Joined: January 19th, 2017, 10:28 pm
Location: Idiot from northern Europe

Re: New/Delete...New[]/Delete[]

Post by Yumtard » June 29th, 2017, 1:42 pm

Cool! You did it different (most likely better) than i did.

Thanks for sharing!

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: New/Delete...New[]/Delete[]

Post by albinopapa » June 29th, 2017, 5:07 pm

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

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: New/Delete...New[]/Delete[]

Post by chili » July 1st, 2017, 5:36 am

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.
Chili

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: New/Delete...New[]/Delete[]

Post by albinopapa » July 1st, 2017, 8:07 am

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

User avatar
DEM0N194
Posts: 28
Joined: April 15th, 2017, 4:14 pm
Location: Slovakia
Contact:

Re: New/Delete...New[]/Delete[]

Post by DEM0N194 » July 8th, 2017, 4:05 pm

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)

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: New/Delete...New[]/Delete[]

Post by albinopapa » July 8th, 2017, 6:38 pm

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.
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

User avatar
DEM0N194
Posts: 28
Joined: April 15th, 2017, 4:14 pm
Location: Slovakia
Contact:

Re: New/Delete...New[]/Delete[]

Post by DEM0N194 » July 9th, 2017, 5:40 pm

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

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: New/Delete...New[]/Delete[]

Post by albinopapa » July 9th, 2017, 6:22 pm

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

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: New/Delete...New[]/Delete[]

Post by chili » July 10th, 2017, 1:09 am

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.
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.

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

Post Reply