refcounting and protecting against delete

[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!

--
Pierre Phaneuf
http://advogato.org/person/pphaneuf/

[Leor Zolman]

On Sat, 03 Apr 2004 18:10:18 -0500, Pierre Phaneuf <[e-mail]>
wrote:

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
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!

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Sat, 03 Apr 2004 18:10:18 -0500, Pierre Phaneuf <[e-mail]>
wrote:

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
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!

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html