ObjectIsDynamic

A possible alternative based only on C++, in an "isntrusive smart pointer environlment" (like the one described here) can be obtained by considering the following issues.

If a class contains a reference counter, it is typically referenced by a somewhat intrusive smart pointer (a class with a dereference and member access operators, calling an “addref” and “release” method on an object when receiving it or leaving it).

In such an environment, a simple alternative is to have a common virtual base for any reference-counted object (say “class counted”) with an overridden new / delete operators, whose new marks a static flag that’s used by counted::counted() to call addref if not marked. That is: the counted class consider the stack as a reference to it. If so, no leaving smart pointer can destroy the object, since -even after all smart pointers have gone- the referece count will be “1”.

To allow re-entrancy (an object that call new for another during contruction) a “stack” cand be used,
Here’s a sample:

/// runtime-type counted object (referrable by intrusive pointers)

interface counted_if
{
    virtual void addref(unsigned n=1)=0;
    virtual void release(unsigned n=1)=0;
    virtual unsigned get_refcount()=0;
};

// counted implementation
// NOTE: not thread safe.

class counted:
    public virtual counted_if
{
public:
    //must not copy the counter in "counted"
    counted() { init(); }
    counted(const counted& c) { init(); }
    counted& operator=(const counted& c) { return *this; }
    virtual ~counted() { ASSERT(!refcount || refcount==1); }

    virtual void addref(unsigned n=1)
    {
        refcount++;
    }
    virtual void release(unsigned n=1)
    {
        refcount--;
        if(!refcount) delete this;
    }
    virtual unsigned get_refcount() { return refcount; }

    void* operator new(size_t s)
    {
        void* p = ::operator new(s);
        //keep the newly allocated area adress-range
        heapcreating().push(creating_t(p,s));
        return p;
    }

    void operator delete(void* p)
    {
        ::operator delete(p);
    }

private:
    unsigned refcount;

    typedef std::pair<void*, size_t> creating_t;
    typedef std::stack<creating_t> stack_t;

    static stack_t& heapcreating()
    { static stack_t s; if(s.empty()) s.push(creating_t(0,0)); return s; }

    void init()
    {
        refcount=0;
        creating_t& cr = heapcreating().top();
        if((char*)this < cr.first || (char*)this >= ((char*)cr.first + cr.second) )
            addref(); //we aren't "new", hence consider us as "referred"
        else
            heapcreating().pop(); //reset the flag
    }
};

To thread safe, at this point, we need nothing more than a critical section signaled during new and resetted into init().

2 bugs found.
> recompile ...
65534 bugs found.
D'Oh! | :doh:

Hi Emilio,

I want to show a way for doing the code thread-safe. I think that, starting with the idea of thread local storage objects and making improvements of their usage (in this case through a list of objects associated to each thread), people can solve many thread related issues or give them another point of view for the problem.

Best regards,
Mauro H. Leggieri

It would have to be a matter of poor design and poor programming for someone to have to rely on a class to tell whether an object he/she defined, was instantiated on the heap or not. Come on!!! You ought to know if you instantiated the object on the heap.

Even if you're dealing with legacy code, a little research could tell whether an object was instantiated on the heap.

The only time I could see this technique being really useful, is if you're dealing with third party libraries and you don't know how a certain object was instantiated. Then I could see something like this being really handy.

The other thing is, you DON'T have to be working with an MFC application to use this technique. You could just as well be working with an SDK sample. It's just that the macro is present in a file that is part of the MFC "Include" files.

Lastly, the author uses the "PASCAL" calling convention as part of his function calls which is now obsolete. It could be replaced with WINAPI, AFXAPI, or by the "/Gd" or the "/Gz" compiler option.

Wink | ;)

William

Fortes in fide et opere!

Hi, William.

It happened to me too many times that I have classes that I allocate them on the stack, or they are global variables or I allocate them on the heap, depending the situation.

For example, I use a class that has a reference counter and detect if it is on the heap. Then, anywhere in my code I can make a object->release() and free it (if the counter reaches zero) without leaving memory leaks and without worrying about calling the delete operator on global/stack objects.

Obviously I can put a simply flag in the object's constructor and determine where the object is. But the main purpose of the code is to simplify things. And, in my case, i don´t worry about setting that flag depending if I use the new operator or not.

I use MFC to show tls manipulation but it can be easily replaced for a custom code.

About PASCAL calling convention, yes, I know that is obsolete. I put them by inertia Smile | :)

Best regards,
Mauro H. Leggieri.

This worked in my trial MFC dialog-based app for pointers to two classes, one on the stack and one declared with new...

No derivation required, no overriding, etc.
Not exactly high speed (the virtualquery takes time), but probably easier to use!

BOOL WINAPI IsOnStackOrNot(<br />
	LPCVOID pObject<br />
){<br />
    BOOL bRetVal = FALSE;<br />
<br />
    if( pObject ){<br />
<br />
        LPVOID  pStack;<br />
        MEMORY_BASIC_INFORMATION TheMemoryInfo;<br />
				<br />
        // get stack address into local value<br />
        _asm mov eax, esp;<br />
        _asm mov pStack, eax;<br />
<br />
        // get memory base of local stack region<br />
        if( sizeof(TheMemoryInfo) <= VirtualQuery(pStack, &TheMemoryInfo, sizeof(TheMemoryInfo)) ){<br />
            // see if our address is within stack allocation range<br />
            // then it is on the stack, otherwise, it is on the heap somewhere<br />
            if( ((DWORD)pObject >= (DWORD)TheMemoryInfo.BaseAddress) &&<br />
                ((DWORD)pObject <= ((DWORD)TheMemoryInfo.BaseAddress + (DWORD)TheMemoryInfo.RegionSize) ) ){<br />
                bRetVal = TRUE;<br />
            }<br />
        }<br />
    }<br />
<br />
    return bRetVal;	<br />
}

-- modified at 18:21 Monday 12th September, 2005

BTW - Must be object declared on stack of same thread as this function is called from.
So, that could be one disadvantage, but hey, you should be deallocating from the same thread as you allocated anyway, if you REALLY want to play safe.

Boy am I glad all my code formatting was preserved ... Mad | :mad:

A neat alternative. Quicker and better than deriving class (etc).

Thanks!

Big Grin | :-D

William

Fortes in fide et opere!

Hi Blake,

Nice piece of code. My target was to distingish between objects allocated on the heap or not on it, mainly for memory release. In Windows I can also use HeapWalk to check if the object was allocated on the heap but there isn't a HeapWalk function in Windows CE. Also, I have some classes that I had to override the new operator replacing them by the GlobalAlloc (or VirtualAlloc) functions so they aren't on the process heap.

About deallocating objects in the same thread that created it, sometimes is difficult to implement. In my case i'm developing a server that uses Completion Ports and any thread can create an object that handles a new connection (using AcceptEx) and the object can be destroyed (e.g. for a connection lost) in any other thread waked up by the system when data arrives to the completion port.

Greetings,

Mauro H. Leggieri

ObjectIsDynamic

Introduction

Using the code

Known issues

License

Comments and Discussions