#149654 - Rajveer - Wed Jan 23, 2008 1:59 pm
If you have 2 pointers to some memory, and you free one of the pointers so it becomes NULL, does the other pointer also become NULL?
#149657 - gmiller - Wed Jan 23, 2008 3:02 pm
No ... neither becomes NULL unless you make them so ... free'ing or deleteing memory does not NULL the pointer.
#149661 - Rajveer - Wed Jan 23, 2008 3:56 pm
Ah, I was under the impression that freeing made it NULL. Don't know why. Cheers!
#149665 - Miked0801 - Wed Jan 23, 2008 5:09 pm
A WeakPtr would do this.
#149668 - silent_code - Wed Jan 23, 2008 5:37 pm
i know the issue is kind of solved, but for the beginners i'll add a bit of an explenation:
the pointers would still point to the same memory location they did before, because their values (the adresses they point to) were not changed. if you then write to or read from that location, the behaviour you'll get it (i guess) depending on the compiler and platform, but you'd propably get a segmentation fault or read the old data or overwrite the old/some other new data.
add a ptr = NULL; after you delete/free to at least solve the problem for the pointer, currently available to the relevant section of code, that was deleted/freed (<- means the pointer, not the code).
you also don't want to delete/free NULL pointers, so check:
| Code: |
if(ptr)
delete prt; // use delete [] for arrays! in C use free(ptr); (wasn't it? it's kinda long ago i used _alloc/free! ;^p)
prt = NULL; |
happy coding!
#149674 - sajiimori - Wed Jan 23, 2008 7:02 pm
Mike's talking about a template we use at work that automatically nullifies pointers to deleted objects.
Life just isn't the same after dangling pointers are a thing of the past...
#149686 - Miked0801 - Wed Jan 23, 2008 10:31 pm
Of all the things C++, Boost Smart Pointers are still the thing I use the most of a daily basis followed closely by the container classes. Objects are nice and all, but those save me daily time :)
#149687 - gmiller - Wed Jan 23, 2008 11:27 pm
Also free and delete you pass the pointer by value so you can not change the pointer itself only the data that the pointer points to ... Not that anyone probably cares. The free and delete function would need to accept at pointer to a pointer to change the pointer value itself but these type are the ones that give people brain pain ... (we ex-assembly guys take them in stride)
#149691 - sajiimori - Thu Jan 24, 2008 1:34 am
Trying to automatically nullify pointers passed to 'delete' is like hand-crafting a sophisticated squirt gun to put out the fire that's burning down your house.
Attempted "solutions" to memory leaks and dangling pointers are laughably impotent given the existence of smart pointers.
#149695 - gmiller - Thu Jan 24, 2008 3:16 am
That is correct if you are using C++ but not C and smart pointers actually implement what you say (nulling or invalidating pointers when they are no longer referenced). When the last "smart delete" is done the memory is deallocated and the pointer is cleared in your case.
In C it is up to the programmer to determine when the last reference is made to a pointer and then free if. So .. if I free the data then it MUST be nullified because the data is no longer stored there. Of course in C there is no constructor/destructor so it is apparent where data is created and apparent when I choose to destroy the data.
Of course smart pointer can be implemented in C as well it is just a little more work. I use smart pointers in C (my implementation and others) and C++ (the standard implementation). I choose to not do them in C when I do not want the overhead but it is my choice and not one that everyone would make.
#149699 - sajiimori - Thu Jan 24, 2008 4:10 am
C does not have RAII, whichever way you cut it. Without RAII, smart pointers are not very smart at all.
Reference counting is one of many things you can automate with smart pointers. I only use reference counting when it's the best solution -- i.e. the one I'd also use in C.
A smart pointer like boost::scoped_ptr solves memory leaks at virtually no cost.
Anyway, a big part of my original point was that nullifying the pointer that's passed to 'delete' is insignificant compared to the much larger problem: Other pointers to the same object may still exist.
I've seen a great deal of fancy footwork done in C to handle this problem, such as batch deletion once per frame, or replacing all potentially unsafe pointers with ID values instead. These solutions carry serious architectural and efficiency costs, but without RAII, better solutions are too hard to enforce consistently across a constantly growing and changing codebase.
#149702 - tepples - Thu Jan 24, 2008 4:44 am
| sajiimori wrote: |
| C does not have RAII, whichever way you cut it. Without RAII, smart pointers are not very smart at all. |
Does the name RAII turn people off because it's so close to RIAA?
| Quote: |
| I've seen a great deal of fancy footwork done in C to handle this problem, such as batch deletion once per frame, or replacing all potentially unsafe pointers with ID values instead. |
In other words, forms of tracing garbage collection.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149707 - sajiimori - Thu Jan 24, 2008 6:25 am
RAII is a crappy name indeed. It's hard to remember without thinking of what it stands for, and it's hard to pronounce.
Since the most salient feature of RAII is that objects do externally-relevant work when they go out of scope, it could be called "Object Destruction Does Something". It's even slightly mnemonic: cleaning up "odds and ends" upon leaving a scope.
#149731 - elwing - Thu Jan 24, 2008 4:23 pm
reference counting FTW :)