3

When implementing reference counting in objects the "release and possibly delete object" primitive is usually implemented like this:

void CObject::Release()
{
    --referenceCount;
    if( referenceCount == 0 ) {
       delete this;
    }
}

First of all, delete this looks scary. But since the member function returns immediately and doesn't try to access any member variables the stuff still works allright. At least that's how it is explained usually. The member function might even call some global function to write to a log that it deleted the object.

Does the C++ standard guarantee that a member function can call delete this and then do anything that will not require access to member variables and calling member functions and this will be defined normal behaviour?

sharptooth
  • 167,383
  • 100
  • 513
  • 979

3 Answers3

6

See C++ FAQ.

I don't have a copy of the standard, but the best "reference" I could find with a google search is this.

To quote the above:

So now I'm wondering if there is anything in the C++ standard that guarantees that a "delete this;" won't crash the program when the function returns.

Nobody can give you such guarantee, because it can crash.

Not according to the standard. The standard is quite clear that the only problem is if the object is used after delete. And the standard also states pretty clearly (in §3.2/2) when an object is "used", and when it is not.

seaotternerd
  • 6,298
  • 2
  • 47
  • 58
Alok Singhal
  • 93,253
  • 21
  • 125
  • 158
  • 1
    That page doesn't cite the standard. It's all very well to take some dude's word for it (granted, a dude who was on the C++ standard committee), but I suspect sharptooth would like to see the evidence for himself. – Steve Jessop Dec 08 '09 at 11:47
  • That page leads to another question: http://stackoverflow.com/questions/1866461/why-should-i-not-try-to-use-this-value-after-delete-this – sharptooth Dec 08 '09 at 12:00
  • Stack Overflow is meant to be a place to find answers, not a place to find something that eventually leads to an answer. If your answer is just a link, please provide a summary of what's at that link. – Rob Kennedy Dec 08 '09 at 15:55
  • @Steve: Technically anybody can turn up to the C++ standards meetings. But has he contributed any seminal papers? Anything that has even lead to a discussion? I don't know just asking. – Martin York Dec 08 '09 at 15:57
  • @Steve: yes, it's not a reference to the standard, but I don't have a copy of the standard with me, so that was the best I could do. Point taken. @Rob: Sure, but C++ FAQ is a well-known website, and has been around for much longer than stackoverflow. But for completeness, the link describes if it's legal to do "delete this" in C++. – Alok Singhal Dec 08 '09 at 16:18
3

This problem has a number on implications, covered best in Item 27 (10 pages) of Scott Meyers book:

More Effective C++: 35 New Ways to Improve Your Programs and Designs

If you dont have this book, buy it as well as its predecessor

Effective C++: 55 Specific Ways to Improve Your Programs and Designs

They are no "how to" Programming learning books, but rather give clear and straight (and explained) advice what to do and what not to do.

EDIT:

Very briefly the item covers:

  • Item 27 Requiring or prohibiting heap-based objects-

Paragraphs are titled:

  • Requiring Heap-based-Objects
  • Determining wether an Object is on the Heap
  • Prohibiting Heap-based-Objects

One of the Problems is, that you must not delete a object thats created on the stack (local objects created not using new) - this is a illegal case and will lead to a crash. But there are more implications about this items.

I can only repeat myself: Every C++ Programmer should know these books. They won't cost you too much time.

RED SOFT ADAIR
  • 12,032
  • 10
  • 54
  • 92
  • 1
    Could you please provide a summary of what Meyers says? At the very least, tell what the *title* of "Item 27" is so we can know what to expect and what to look for. – Rob Kennedy Dec 08 '09 at 15:57
1

Yes, that will behave like deleting any other object.

Naveen
  • 74,600
  • 47
  • 176
  • 233