This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ SEGMENT fault and vtable issu


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]