On 19 October 2012 02:44, Arthur Schwarz wrote: > Hi Jonathan; > > Because I'm a wise old critter (or serendipity struck - > choice is yours), I think that I found the cause of my > difficulties. > > 1: I constructed my own 'new' and 'delete' operators. Often a bad idea. > 2: I am constructing a list processor with a list header > which has a count of references to the itself. > 3: When the reference count is zero, I delete the header > and the list contents. > > I had expected that the C++ kernel would not participate > in this. However, what appears to be happening is that when > the C++ kernel sees a delete, the object 'vptr' is removed. > This is not the behavior I want. In particular I would like > to: > 1: Retain the C++ 'delete' operator. > 2: Remove the 'vptr' only when I want. I don't know what you mean by "remove the vptr" but it sounds like you're trying to inspect the memory of non-POD objects after they've been destroyed. Don't do that. It's undefined behaviour. > Creating a method for a delete seems unnatural and needlessly > tedious for someone using the software. Do I have any control > over when the 'vptr' is removed? Alternatively, is there a > non-gcc dependent way of reinserting the 'vptr' into a deleted > (but not yet deleted) class object? What is a deleted but not yet deleted object?! I think you should step back and find a different approach that doesn't involve writing your own new/delete operators that have undefined behaviour. The cause of your segfault is writing code with undefined behaviour, so the fix is to not do that.
