In this lecture I want to talk about some guidelines on how to use dynamic memory properly and that's
really just my guidelines that I've developed over the years.
And you once you have some experience you can decide for yourself if you want to keep using them or
develop your own.
So one rule I like to follow is that whoever made the memory should be the one responsible to delete
it.
So let me walk you through what I've done here.
So we have two functions.
So this first function right here returns a dynamically created integer.
And this next function just uses the integer.
You'll see I use funny names of Schultes plain in a second.
So in here Maine is issuing the call to create a new integer using this function func right here.
And it assumes that it knows that func actually does create a new integer doesn't just pass you back
pointer of some local variable.
Ok So ultimately then it's up to Maine to delete the pointer once it's done with it.
OK so that's why you'll see down here I say delete the pointer
and this is the concept of memory ownership thing.
I would add to this is to name the variables in such a way that it indicates who owns what.
So that's kind of what I've done here.
Usually when I have a pointer that actually owns some memory all kind of put a prefix on the name and
actually say oh pointer.
So this stands for owning pointer.
So it owns the memory pointed to by this pointer is what this really sets.
OK.
So it takes ownership of the memory and you'll see down here and this use all have this kind of no pointer.
Well this stands for non owning pointer.
OK.
So this.
So this guy right here is use function can use the pointer however it likes but it knows not to delete
it.
It's not its responsibility.
OK so that's what no pointer.
That's my convention for the name of it.
OK so it's very important to be able to read the code and know who owns was.
So like I said if I pass a pointer to a function that I know I didn't own the pointer then I put the
no pointer in front of it.
OK so I find this is a very good way to remember who owns what and who's responsible for deleting the
memory.
And once you delete the pointer you should always set it to null pointer after.
And this is because really you're still pointing to the same memory address even after it gets deleted.
But since it really doesn't since is it's not really accessible by you anymore at least it shouldn't
be you shouldn't keep a reference to it.
And so that's kind of the reason why.
So if I did anything with the pointer after we delete it it's completely undefined behavior.
So we don't know what's going to happen if I use it in any way.
And so that's why I put the null pointer here because if I do use it and Id reference it Liesel crash
in L.A. where I crashed.
So it's called the dangling pointer.
I don't set you know pointer.
And these are really the primary guidelines that I use.
In fact we have too many others.
It's really just make sure I know who points to what and who owns what and if they don't own it then
I should say that they don't own it.
And one last thing here.
You saw the example before where so Ulos in this function and I return a pointer OK.
And we saw an example before where I said something like this.
Add A.
X equals 5 and then I kind of return the return the address of the X..
Well this is wrong because we know that X will be destroyed by the end of the function.
But here since I'm returning a new int i know that it won't be destroyed because it's comes from the
heap and we as per armorers have to delete it not and it's not automatic like it would be if it was
a local variable.
And so that's why doing this is OK.
This is totally fine and it's OK to do so I just want to go over it in the next lecture I want to talk
about the pitfalls of not being careful when using dynamic memory.