Re: refcounting and protecting against delete

From: Leor Zolman (leor_at_bdsoft.com)
Date: 04/04/04 

Date: Sun, 04 Apr 2004 02:28:42 GMT

On Sat, 03 Apr 2004 18:10:18 -0500, Pierre Phaneuf <pp@ludusdesign.com>
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

Relevant Pages

  • refcounting and protecting against delete
    ... we are in the process of migrating to a component ... use "delete obj" when obj is a pointer to IUnknown or a derivative. ... I thought of making the destructor protected in IUnknown, ... with older versions of compilers, but I guess that's how progress goes. ...
    (comp.lang.cpp)
  • Re: auto_ptr compile error
    ... delete statement from destructor of auto_ptr requires the declaration of destructor of wrapped object? ... it leaks sometimes. ... Owner is a class that owns an instance of Thing. ... If you take a closer look, there was actually a compiler warning about it, but no error. ...
    (microsoft.public.vc.language)
  • Re: Virtual dtor and placement new.
    ... templatevoid CallDestructor(T*p) instead of void * helps the ... > could then store a pointer to the original memory and call MyDelete ... The functor is a good solution, but then you don't call the destructor ... unwinded by the compiler. ...
    (comp.lang.cpp)
  • Re: why should i use a virtual deconstructor?
    ... Or the compiler might choose at random ... | destructor being called or a crash because of a non-virtual ... Thanks for the insights James. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Internal compiler error problem
    ... INTERNAL COMPILER ERROR (compiler file ... Maybe the release mode tried to inline the destructor and goofed it ...
    (microsoft.public.vc.language)