Re: Virtual dtor and placement new.

From: Giancarlo Niccolai (Noone_at_nothing.org)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 19:59:59 GMT

Tobias Güntner wrote:

> // It is assumed that p is of type T*
> template<class T>
> void CallDestructor(void* p)
> {
> static_cast<T*>(p)->~T();
> }
> typedef void (*DestructPtr)(void*);

<rip>

It is exactly the solution I found before today, and it gives exactly the
problem I reported. As you can see, template expansion of the ~T() call
will call the destructor associated with the class of the POINTER you pass
to CallDestructor(), and not the class of the OBJECT you pass it. So (using
template<class T> void CallDestructor( T*p) instead of void * helps the
compiler a little):

class B: public A {
..
};

A* obj = new(mem) B;
B* obj1 = new(mem) B;

...
CallDestructor( obj ); // resolves in template A, calling p->~A;
CallDestructor( obj1 ); // resolves in class B

or, maintaining the void * as parameter,
CallDestructor< ?what here? you have do decide at compile time>( obj );

and what is in obj, if it can dynamically change at runtime?

> It is possible to store this information in a smart-pointer, however.
> For example boost::shared_ptr, where you can pass a functor that can do
> additional cleanup when the memory is to be deleted (i.e. this functor
> could then store a pointer to the original memory and call MyDelete
> automatically).
> Using a smart pointer seems to be the most reliable way IMHO.

The functor is a good solution, but then you don't call the destructor
anymore. This means that stack-allocated object cannot be automatically
unwinded by the compiler. You have to allocate all the items in the heap,
as a smart pointer would not be able to tell a heap-allocated item from a
stack allocated one, while the overloading of the delete operator is.
>
> You could as well derive your object from a special base class that
> knows the destructor (works basically like the first approach, but is
> not so low-level and more obvious. I guess I should have mentioned this
> version first ;) )

Uhm; first of all, you may not want all the objects in your application to
be virtual. For really high-speed aps, as the vtable and the objects are
unlikely to be kept near in memory, the memory cache flushes to access the
vtable and then the object repeatedly may cause an unacceptable operational
downgrade. Secondly, it does not cure the problem, as the problem is
EXACTLY that of being unable to virtualize the destructor due to a lack in
C++ grammar definition: you can call every method by its object-specific
representation EXCEPT for the destructor, which you may call only with its
CLASS specific representation. You may call a->method(), and method is
relative to a object, so the compiler has to find a way to address it: is
it a vtable entry? is it an inline method? what kind of pointer is A? can
it hold virtual objects?. But with destructors, you may call only
a->~CLASSNAME(); and then you reference the classname explicitly, the
compiler won't try to understand what A may be except for that class
instance. The only way to call a destructor by object instance specific
representation is to use delete, but yet delete does not only call the
destructor, but also free the memory... that's the lock-in situation I was
facing; overloading delete seems the only possible solution, and actually,
it worked, but then WHY, is my question, WHY this possibility is explicitly
excluded by the literature about the placed new() operator?

Giancarlo.

Relevant Pages

  • Re: C- Syntax to allocate Global variables to consecutive memory locations
    ... nothing to stop a platform from simply not having any addressable memory address (void *)0x8000. ... And there sure as manure is no requirement for this memory, if it exists, to be _writable_. ... Even if were possible, in this case, to tell the compiler at the memory at 0x8000 works as you want, then there would still be other assumptions. ... It's possible that the code will contain comments to that effect, but it might be implied by the platform in use. ...
    (comp.arch.embedded)
  • Re: faster access private or public?
    ... > void g ... assuming the above is well formed (the Foo destructor might be ... private, which was the example I gave earlier: "I can't think of a way ... If the compiler knows that a particular function call cannot possibly ...
    (microsoft.public.vc.language)
  • Re: Callback Function Stack Overflow
    ... void a; ... process's memory does not increase. ... My guess is that the compiler realizes what you are doing, and implements it with gotos instead of function calls. ...
    (comp.lang.c)
  • Re: C++0x atomic and reference counter
    ... you opt for low-level ordering constraints then you have to specify ... as they cannot legally access the memory locations. ... Does it matter if the destructor is empty as in the example provided? ... and thus needs the acquire fence. ...
    (comp.programming.threads)
  • 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)