Overloading delete operator to delete something allocated in library

Question

I'm using framework which has a class Register, into which I'm able to register instances of A.

Register r;
A * a1 = new A();
r->register(a1);
A * a2 = new A();
r->register(a2);

Register will take ownership and deletes all registered As when going out of scope.

I want to modify As behaviour in shared library (.so in my case), so, I'm gonna do something like this (in the library):

class B : public A {
    ...
}

B * get_customized_a() {
    return new B();
}

And then in main program

Register r;
A * a1 = get_customized_a();
r->register(a1);

but now a1 will be deleted in main program, not in the library! Which from I understud is a big no-no.

So how to solve this?

---

I've come up with two solution:

1) Use A and customize it by stand-alone function

in plugin:

void customize_a(A * a) { ... }

in main program:

Register r;
A * a1 = new A();
customize_a(a1);
r->register(a1);

I must say I don't like it that much :/

2) Overload delete operator for class B

in plugin

class B : public A {
    ...
    static void operator delete(void * ptr) {
        ::operator delete(ptr);
    }
}

in main program:

Register r;
A * a1 = get_customized_a();
r->register(a1);

However, I never overloaded operator delete before so I'm not sure if this will even work (as intended).

3) Is there any approach I missed? Is there a better solution?

Thank you all.

Answer 1

If you delete a class by using a pointer to one of the base classes then the destructor has to be virtual in the base class regardless of the location of object creation and destruction. Module boundaries have nothing to do with this.

On the other hand if the construction and destruction of an object happen in different modules it is a problem only if the new and delete operator of these modules allocate/deallocate memory from different pools. This can be the case for example if these modules are linked against different versions of the runtime library. A similar case is when you explicitly override the new and delete operators in the libraries and do the allocation yourself from different pools without cooperation between the allocator code of these modules. In this case a virtual destructor doesn't save you from the problems because the construction of the object allocates memory using the allocator/pool of one module, and you call the delete operator of another module that tries to deallocate the object from a completely different pool. The result is usually a false "heap corruption" runtime error or something similar.

If you ever face the above problem then a correct solution is introducing both a virtual destructor and a virtual Release() method in the base class. The Release() method should delete the object with an ugly delete this;. When you pass the constructed object to a foreign module then it has to delete the object by calling the Release() method instead of directly deleting it and this way the Release() method deletes the object with the delete operator of the module that owns the class and the instance. Often this technique is coupled with smart pointers so that the foreign module references such objects with smart pointers that automatically delete the objects by calling the Release() method.