Removing an overload operator in a base class

Question

From the C ++ standard (ISO / IEC 14882: 2003 (E)), §12.5.4, on operator delete overloading:

If an expression expression begins with a unary :: operator, the name of the delete function is used in the global scope. Otherwise, if the delete expression is used to free an object of the class whose static type has a virtual destructor, the maladaptation function is the one found in the definition of the virtual destructor of the dynamic type (12.4). Otherwise, if the delete expression is used to free an object, the class T or array, the static and dynamic types of the object must be identical, and the name of the function of the allocation is looked in the domain T. If this search does not find the name, the name is looked in the global scope. If the search result is ambiguous or unavailable, or if the search selects the release function, the program is poorly formed.

§ 12.5.7 is also interesting:

Since the functions of distributing and freeing members are static, they cannot be virtual. [Note: however, when the expression-expression of the expression-expression refers to an object of the class type, since the actually called release function is displayed in the region of the class, which is the dynamic type of the object, if the destructor is virtual, the effect is the same. For example,

 struct B { virtual ˜B(); void operator delete(void*, size_t); }; struct D : B { void operator delete(void*); }; void f() { B* bp = new D; delete bp; // uses D::operator delete(void*) } 

Here, the storage for an object without an array of class D is freed from D :: operator delete () due to the virtual destructor.]

After reading this, I wonder ...

• Is this part of the standard fully supported by all major C ++ compilers (MSVC ++, GCC)?
• If so, how did they do it? Hidden virtual function? A "special" virtual destructor call? RTTI?
• Using an example from the standard: can there be problems if f () and D :: operator delete () are defined in separate EXE / DLL / DSO? (Assuming everything is compiled using the same compiler, of course)

§5.5.5.5 may also be relevant:

In the first alternative (delete an object), if the static type of the operand is different from its dynamic type, the static type should be the base class of the dynamic type of the operand, and the static type should have a virtual destructor or undefined behavior. In the second alternative (delete array), if the dynamic type of the object to be deleted is different from its static type, the behavior is undefined.

Answer 1

I don't know much about VC ++ ABI, but Itanium ABI is well documented.

Raising the name change scheme , you can see:

 <ctor-dtor-name> ::= C1 # complete object constructor ::= C2 # base object constructor ::= C3 # complete object allocating constructor ::= D0 # deleting destructor ::= D1 # complete object destructor ::= D2 # base object destructor 

Interest: D0 # deleting destructor , which means that even if delete not virtual, since it is called from a virtual destructor, it can be considered virtual for all effects and purposes.

Answer 2

After digging into the assembly code emitted by GCC 4.8

GCC will create two pieces of code (for a class whose destructor is virtual):

 One is assembly snippet#1 for {Destructor + Dealloc} The other is assembly snippet#2 for {Destructor only} 

And for a class whose destructor is not virtual, a call release function command will be generated at the place where you call delete.

(After discussion, suppose the destructor is virtual) So, for the following code:

 delete C // This will be translate as call snippet#1 for the correct dynamic type 

And if you use the following code:

 p->C::~C() // this will be translate to call snippet#2 

Thus, the deallocate function is associated with a virtual destructor. Therefore, I think this will answer your question about how the deallocate function is implemented as virtual, but also static.