Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!ut-emx!jamshid From: jamshid@ut-emx.uucp (Jamshid Afshar) Newsgroups: comp.lang.c++ Subject: Re: Object pointers, and destructors Summary: setting p=0 after delete is a good thing Message-ID: <50253@ut-emx.uucp> Date: 10 Jun 91 07:47:30 GMT References: <19944@sdcc6.ucsd.edu> <2289@godzilla.tcs.com> Distribution: comp Organization: The University of Texas at Austin; Austin, Texas Lines: 67 In article warsaw@nlm.nih.gov writes: <> <> > Robert> It is consistent with the C++ philosophy "it doesn't work > Robert> this way by default but you can do it yourself" > >Hmm. I for one would've liked to see ::operator delete take a void*& >so you *could* do this if you wanted (which, right now, you can't). >Still after listening to what more experienced programmers were >saying, and getting some C++ time under my belt, I think you really >need to take a much more careful approach when throwing pointers to >objects around. Using ::operator delete could lull one into a false >sense of security :-). > >-Barry > >"When in doubt, cout." Page 63 of the ARM mentions that modifying the pointer after a delete would be useful for debugging. It would have to be something the compiler does, as there is no way for the programmer to do it by overloading operator delete. operator delete cannot take a reference to a void* because while the _value_ of any object pointer can always be converted to the _value_ of a void*, the actualy object pointer is not a void* (e.g. you can't pass an int** to a void**). This is an important fact that helps in understanding why you can't pass the 'address of a pointer to a Derived' to a function expecting the 'address of a pointer to a Base' (a c.l.c++ faq-- has anyone taken up the challenge of maintaining a FAQ list?). I do believe that setting the pointer to 0 (or some "bad" address) after a delete is well worth the effort as a significant number of bugs are caused by referencing objects after they are deleted. This is a very nasty bug because in alot of C++ implementations, using freed memory will _not_ cause your program to crash (especially during testing :-). I always set the pointer to 0 after a delete in my code and it has caught alot of bugs (one particularly bad one was a compiler bug causing the destructor to be called twice). Of course there is no way to keep another pointer from referencing the freed memory, but the simple case is common enough and easy enough to prevent without a significant performance penalty (I was relieved to see a poster unanimously flamed in comp.lang.c for asserting that testing p!=0 in free(p) is a significant performance penalty "when you have 1000 free's"). I definitely agree that you have to be very careful with pointers in C/C++. Since I've been using C++ I have tried to restrict my use of pointers to private class member variables and rarely even use them there because of references or my complete disregard for efficiency :). "Smart" pointers, objects that behave like pointers but keep a reference count and can do other checking, seem like they would be helpful, but I've never actually created a smart pointer class for any of my classes. Does anyone have a simple example they can post? It seems like templates would help in creating smart pointers. As a matter of fact, it seems like templates would help in alot of non-obvious (at least to me) ways. For example, someone posted a while back a simple template which would "automaticly" create operator!=() if your class defined a operator==()). Jamshid Afshar jamshid@emx.utexas.edu "Keep sigs short."