andrewt@watsnew.waterloo.edu (Andrew Thomas) (09/22/89)
In article <13510@well.UUCP> nagle@well.UUCP (John Nagle) writes: > No good. What you have done here may result in a pointer to > space that has already been released with "delete". Think about > the sequence of events implied here. > > 1. my_func returns a string object into a temporary variable > allocated by the compiler. > 2. The "char *" conversion extracts the pointer to the array > of characters from the string object. This pointer is to > space obtained with "new" when the string object was allocated. > 3. The destructor for the temporary string object is called, > resulting in the release of the space holding the characters. > 4. The pointer obtained in step 2, which now points to free > space, is passed to printf. > > To make it clear that this approach is wrong, try putting code in the > destructor to clear the buffer to some garbage character before releasing > it with "delete". > > John Nagle In previous postings I got nailed to the wall for mixing printf with a C++ program. I realize the sloppiness of it. I was trying to provide an example which used an automatically created class object as a parameter to any function. Printf was convenient. Aside from that fact, the destructor was still called too soon. Simply replace the call to printf with a call to any function explicitly taking a pointer to character, and use whatever method you see fit to print out its contents. G++ will still destroy the object before the function call is made, thereby destroying the character string before it is printed. I still content that THIS IS A BUG. I think that John has stated my case quite clearly above. As an aside, the following appears in a posting by mx!cbcscmrs@csun.edu: ! deleting Hello (1c30) ! deleting Hello (1c00) ! Function: Hello (1c30) ! ! Note only 6 destructors, and 8 constructors. Also note that memory ! address 1c30 is deleted with an automatically called destructor before ! the String instance is actually used. !//** You have to look at the assembly code to actually make that !//** statement. In the code I looked at, everything is as it should !//** be. It's been a year since I said this, but it's still true: the !//** most difficult way to observe code is from the behavior of a !//** program, because under those conditions, you must make !//** assumptions and interpretations. .... ! !Michael How is this possible? I was not aware that there was a circumstance where output to a file (stdout) could actually be printed in a different order from the order in which the output was sent. Unless this possibility exists, I fear that Michael's stance on this point is more dogmatic than logical. -- Andrew Thomas andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo "If a million people do a stupid thing, it's still a stupid thing." - Opus