Hi Jonathon; I thought I'd respond to your comment about overriding 'new' and 'delete' and that its dangerous and should not be used. I agree to the danger but disagree to the 'do not use'. Let me provide the following reasons and experiences. The language developers were cognizant concerning the danger of a user overriding the operators but still made 'new' and 'delete' operators and overrideable, rather than non-overrideable. I don't disagree with them. I think you must be knowledgeable in order to do an override, and as these postings show, I am not been knowledgeable and have sought advice. If we consider not using things that are dangerous, then we should probably not use unsigned integers. Overflows and underflows go undetected. And yet, for better or worse, we use unsigned integers, and accept the consequences, all the time. Following your advice would say that we should not use unsigned integers and perhaps, remove them from the language. As to the case in point, I would rather have comments concerning how to correctly override 'new' and 'delete', or references which increase my understanding, than admonitions saying "do not use". There are, I think, good reasons that overriding was chosen over reinventing. I would be absolutely delighted to have someone provide support in this effort and openly solicit anyone for any help. If after reviewing the design approach, the architecture, and expectations of acceptability to the intended audience the comment concerning "do not use" still stands, then I would feel compelled to change my approach. But it is a stretch for me to change direction now. I do thank you and actively solicit your knowledgeable support on this project. art 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.
