delete this

[Mike -- Email Ignored]

Is:
delete this;
allowed?

I have been using it to close down a thread, and
it has been working. However I just added a:

delete[] buf_; // where: char* buf_;
buf_ = 0;

to one of the destructors, and I got a warning
that I was calling a pure virtual function.

Any thoughts?

Mike.

 

[Daniel Pitts]

Is:
delete this;
allowed?

I have been using it to close down a thread, and
it has been working. However I just added a:

delete[] buf_; // where: char* buf_;
buf_ = 0;

to one of the destructors, and I got a warning
that I was calling a pure virtual function.

Any thoughts?

Mike.

Whether or not it is valid (and I'm guessing it isn't valid), it is
dangerous... You are nearly guaranteed to leave a dangling reference to
now deleted memory. Not to mention you might be deleting an object that
is on the stack, or was allocated in some way that "delete" isn't
appropriate for cleaning up.

 

[Alf P. Steinbach]

* Mike -- Email Ignored:

Is:
delete this;
allowed?

Yes. This is FAQ (Frequently Asked Question). See the FAQ item titled "Is it
legal (and moral) for a member function to say delete this?", currently item
16.15 and available at e.g. <url:
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15> plus at a
host of various mirrors of the FAQ site.

I have been using it to close down a thread, and
it has been working. However I just added a:

delete[] buf_; // where: char* buf_;
buf_ = 0;

to one of the destructors,

The 'buf_ = 0;' indicates that you lack a clearly defined ownership for that
buffer -- that some other destruction code is checking the nullness of 'buf_'.

Instead use e.g. a std::string or a std::vector.

and I got a warning
that I was calling a pure virtual function.

Well that's an unrelated problem.

Try to produce a smallest possible /complete/ example and post it.

Or, fairly likely, the process of trying to create such an example will give you
some "Aha!" insight about what the problem is and how to avoid it.


Cheers & hth.,

- Alf

 

[Mike -- Email Ignored]

On Fri, 20 Feb 2009 04:12:13 +0100, Alf P. Steinbach wrote:

[...]

The 'buf_ = 0;' indicates that you lack a clearly defined ownership for
that buffer -- that some other destruction code is checking the
nullness of 'buf_'.

True. The use of buf_ is unusually complex.

Instead use e.g. a std::string or a std::vector.



Well that's an unrelated problem.

A result of memory abuse, in this case.

Try to produce a smallest possible /complete/ example and post it.

Or, fairly likely, the process of trying to create such an example will
give you some "Aha!" insight about what the problem is and how to avoid
it.


Cheers & hth.,

- Alf

Mia culpa. The error was:

delete[] buf_;
buf_ == 0; // risks memory abuse: can't the compiler catch this?
// Perhaps "Missing lvalue"?

and later:

delete[] buf_; // memory abuse
buf_= 0;

I agree that std::string and std::vector would prevent
the problem, but it wasn't done in this case.

It is working fine now.

Thanks,
Mike.

 

[Daniel Pitts]

Is:
delete this;
allowed?

I have been using it to close down a thread, and
it has been working. However I just added a:

delete[] buf_; // where: char* buf_;
buf_ = 0;

to one of the destructors, and I got a warning
that I was calling a pure virtual function.

Any thoughts?

Mike,

we use it in one instance only: We have reference counted objects, and
when the reference count goes to zero we call "delete this" as pretty
well the last statement in the release() (uncounting) method. it works
for us, with our compiler, and in our system.

Remember that once you have done the call, "this" is invalid, so you
must use no object data nor any virtual methods. And even then be careful!

Andy

Why not use shared_ptr, or some other generic reference counter? For one
thing, it would separate the concern of "reference counting" from the
concern of your actual object.

 

[Juha Nieminen]

Why not use shared_ptr, or some other generic reference counter? For one
thing, it would separate the concern of "reference counting" from the
concern of your actual object.

Because shared_ptr has enormously more overhead without giving any
benefit? (Assuming, of course, that you don't need custom deleters, weak
pointers or for the smart pointer to be thread-safe.)

 

[Ian Collins]

Because shared_ptr has enormously more overhead without giving any
benefit? (Assuming, of course, that you don't need custom deleters, weak
pointers or for the smart pointer to be thread-safe.)

The overhead depends on the use. Yes they can be expensive to copy, but
a decent implemenation will have zeor over head for dereferencing.

 

[Alf P. Steinbach]

* Mike -- Email Ignored:

buf_ == 0; // risks memory abuse: can't the compiler catch this?
// Perhaps "Missing lvalue"?

Don't know if relevant, but if you up the compiler's warning level then it will
likely warn about "statement has no effect". E.g. with g++ '-Wall' or with MSVC
'/W4'. It's IMO always a good idea to ensure a 100% clean compile at highest
"practical" warning level (of course that's formally a completely meaningless
statement but I think you'll understand what I mean! ).


Cheers & hth.,

- Alf