Assigning member values in destructors

[Hugh Jass]

Hey,

I just stumbled over a piece of foreign code where they implemented an own ref counting system and had like this code in their destructor:

~RefCount()
{
// Set reference counts below zero to fire asserts if this object is still accessed
refs_ = -1;
weakRefs_ = -1;
}

and I'm wondering if this makes sense because at first gloss it seems pointless to assign values to an object that's supposed to be deleted. However it's probably intended to detect misuse of other pointers to this object.

However, if I'm not mistaking, debug mode will set a pointers address to sth like 0xfeeefeee if it has been destructed and in release mode assertions aren't active, right? The though behind this is probably that the storage of these variables must not have necessarily been overwritten and previous values might still be in memory when trying to access the deleted object over another pointer. Is that correct?

PS: Sorry if the formatting doesn't work because nothing happens when I mark text and press one the text formatting icons below and the preview also shows an empty windows no matter what I typed in here.

[mutexe]

Looks like those variables are probably static members of the class. In other words they "belong" to the class, and not each instantiation of that class.

http://www.learncpp.com/cpp-tutorial/811-static-member-variables/

[Hugh Jass]

No, it's like this:

struct RefCount
{
    /// Construct.
    RefCount() :
        refs_(0),
        weakRefs_(0)
    {
    }
    
    /// Destruct.
    ~RefCount()
    {
        // Set reference counts below zero to fire asserts if this object is still accessed
        refs_ = -1;
        weakRefs_ = -1;
    }
    
    /// Reference count. If below zero, the object has been destroyed.
    int refs_;
    /// Weak reference count.
    int weakRefs_;
};

And then the class using it does it like so:

/// Base class for intrusively reference-counted objects. These are noncopyable and non-assignable.
class RefCounted
{
public:
    /// Construct. Allocate the reference count structure and set an initial self weak reference.
    RefCounted();
    /// Destruct. Mark as expired and also delete the reference count structure if no outside weak references exist.
    virtual ~RefCounted();
    
    /// Increment reference count. Can also be called outside of a SharedPtr for traditional reference counting.
    void AddRef();
    /// Decrement reference count and delete self if no more references. Can also be called outside of a SharedPtr for traditional reference counting.
    void ReleaseRef();
    /// Return reference count.
    int Refs() const;
    /// Return weak reference count.
    int WeakRefs() const;
    /// Return pointer to the reference count structure.
    RefCount* RefCountPtr() { return refCount_; }
    
private:
    /// Prevent copy construction.
    RefCounted(const RefCounted& rhs);
    /// Prevent assignment.
    RefCounted& operator = (const RefCounted& rhs);
    
    /// Pointer to the reference count structure.
    RefCount* refCount_;
};

[MiiNiPaa]

It is there for debugging to catch most obvious problems.

I'm not mistaking, debug mode will set a pointers address to sth like 0xfeeefeee if it has been destructed

Depend in compiler and its configuration

[Hugh Jass]

Yes exactly, that's what I stated above. If the compiler sets the addresses of all other pointer to 0xfeeefeee then there is no way of accessing the member variable's old values by dereferencing the old but now invalid address, no?

[MiiNiPaa]

If it sets. If it does, then it hase own methods to catch invalidpointer access. If it does not, then we have a chance (depending on optimisation level set) to catch them yourself.