refcounting and protecting against delete

P

Pierre Phaneuf

At my workplace, we are in the process of migrating to a component
system similar to COM (but not COM itself, as we have some space and
portability requirements) that uses refcounting for resource management.

My problem is that I would like to find a way of finding out attempts to
use "delete obj" when obj is a pointer to IUnknown or a derivative.
Since this is a migration, we have a lot of existing code that uses
delete directly, and I feel that since the compiler actually has this
information at compile-time, there might be a good way to do this.

Having our own component system has the advantage that we can modify it
more freely to make this verification in a safe way.

I thought of making the destructor protected in IUnknown, but since a
lot of classes derive from it and use "delete" on other objects, this
has almost no effect.

I thought of putting a private "operator delete" in IUnknown (we do not
overload new or delete anywhere in our code), and making our
(macro-generated) implementation of Release() use "::delete", but it
seems that the code that our compilers (GCC 2.95.4, 3.x and Visual C++
7.1) generates for the classes' destructors needs access to the
"operator delete" of the classes. Annoyingly enough, this used to work
with older versions of compilers, but I guess that's how progress goes.

I am down to the point of using a bool member in my implementation of
IUnknown (for debugging only) that is initialized to false and is set to
true only when Release() calls "delete", having an assert() on it in the
destructor. But I find this rather disappointing, since this can clearly
be determined statically.

Thanks in advance for any idea!
 
L

Leor Zolman

At my workplace, we are in the process of migrating to a component
system similar to COM (but not COM itself, as we have some space and
portability requirements) that uses refcounting for resource management.

My problem is that I would like to find a way of finding out attempts to
use "delete obj" when obj is a pointer to IUnknown or a derivative.
Since this is a migration, we have a lot of existing code that uses
delete directly, and I feel that since the compiler actually has this
information at compile-time, there might be a good way to do this.

Having our own component system has the advantage that we can modify it
more freely to make this verification in a safe way.

I thought of making the destructor protected in IUnknown, but since a
lot of classes derive from it and use "delete" on other objects, this
has almost no effect.

I thought of putting a private "operator delete" in IUnknown (we do not
overload new or delete anywhere in our code), and making our
(macro-generated) implementation of Release() use "::delete", but it
seems that the code that our compilers (GCC 2.95.4, 3.x and Visual C++
7.1) generates for the classes' destructors needs access to the
"operator delete" of the classes.

Just a shot-in-the-dark, since no one else has offered anything yet: Can
you declare those destructors that need access to IUnknown's operator
delete to be friends of IUnknown? Perhaps there's some way of generalizing
it using a template for the friend declaration?
-leor
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top