GNU GCC (g++): Why does it generate multiple dtors?

Developing environment: GNU GCC (g++) 4.1.2

While I’m trying to investigate how to increase ‘code coverage – particularly function coverage’ in unit testing, I’ve found that some of class dtor seems to be generated multiple times. Does some of you have any idea on why, please?

I tried and observed what I mentioned the above by using the following code.

In “test.h”

class BaseClass
    void someMethod();

class DerivedClass : public BaseClass
    virtual ~DerivedClass();
    virtual void someMethod();

In “test.cpp”

#include <iostream>
#include "test.h"

    std::cout << "BaseClass dtor invoked" << std::endl;

void BaseClass::someMethod()
    std::cout << "Base class method" << std::endl;

    std::cout << "DerivedClass dtor invoked" << std::endl;

void DerivedClass::someMethod()
    std::cout << "Derived class method" << std::endl;

int main()
    BaseClass* b_ptr = new BaseClass;
    delete b_ptr;

When I built the above code (g++ test.cpp -o test) and then see what kind of symbols have been generated as follows,

nm –demangle test

I could see the following output.

==== following is partial output ====
08048816 T DerivedClass::someMethod()
08048922 T DerivedClass::~DerivedClass()
080489aa T DerivedClass::~DerivedClass()
08048a32 T DerivedClass::~DerivedClass()
08048842 T BaseClass::someMethod()
0804886e T BaseClass::~BaseClass()
080488f6 T BaseClass::~BaseClass()

My questions are as follows.

1) Why multiple dtors have been generated (BaseClass – 2, DerivedClass – 3)?

2) What are the difference among these dtors? How those multiple dtors will be selectively used?

I now have a feeling that in order to achieve 100% function coverage for C++ project, we would need to understand this so that I can invoke all those dtors in my unit tests.

I would greately appreciate if someone could give me the reply on the above.

GNU gcc and g++

Are the gcc and g++ compilers installed on a MAC OS X machine different from the ones on Ubuntu (Linux) GNU gcc and g++ compilers? I am using Eclipse to develop a C++ program and there is toolchain se

Why does gcc generate verbose assembly code?

I have a question about assembly code generated by GCC (-S option). Since, I am new to assembly language and know very little about it, the question will be very primitive. Still, I hope somebody will

gcc does not generate debugger info when using -g, -ggdb, -g3, or -ggdb3

I’m using GCC 4.4.1 and GDB 7.0-ubuntu on Ubuntu 9.10. However, GCC won’t generate debugger info when using any of the following switches: -g, -g3, -ggdb, or -ggdb3. So when I run the program with GDB

GCC -g file format

GCC -g uses the native file format (stabs, COFF, XCOFF, or DWARF). Which format is used on Linux? How can I prove which file format i

Why does gcc require gmp?

As anyone who has ever built gcc from source knows, gmp is a dependency for gcc. Why is this? In other words, what does gcc actually use it for?

why does gcc search in /usr/include/x86_64-linux-gnu before /usr/include

The gcc manual says that the order of search for system headers for C (not C++) compilation is: /usr/local/include libdir/gcc/target/version/include /usr/target/include /usr/include yet on my system

Updating Apple g++/gcc

What is the difference between Apple gcc and GNU gcc? Is Apple gcc a superset of the standard one? The g++ version information in my OSX shows: $ g++ –version i686-apple-darwin11-llvm-g++-4.2 (GCC) 4

Difference between GCC’s GNU C standards and ANSI C?

Can anybody describe the differences between the GNU C standards of GCC, and ANSI C? Which is better and why?

install multiple versions of g++(or gcc) [closed]

I was wondering if it is possible to install multiple versions of g++ on the same machine without any problem. I use the almost current gcc for my work(4.6.1). Now for my studies, my teacher has given

What does “__G” signify?

What does __G signify in C? I’m using GCC 4.9. I’m using latest MinGW version. I’m compiling with -std=gnu11. I have the following C (being compiled with GCC as C11) code: #ifndef __G #define __G 0 #e


First, the purposes of these functions are described in the Itanium C++ ABI; see definitions under “base object destructor”, “complete object destructor”, and “deleting destructor”. The mapping to mangled names is given in 5.1.4.


  • D2 is the “base object destructor”. It destroys the object itself, as well as data members and non-virtual base classes.
  • D1 is the “complete object destructor”. It additionally destroys virtual base classes.
  • D0 is the “deleting object destructor”. It does everything the complete object destructor does, plus it calls operator delete to actually free the memory.

If you have no virtual base classes, D2 and D1 are identical; GCC will, on sufficient optimization levels, actually alias the symbols to the same code for both.

There are usually two variants of the constructor (not-in-charge / in-charge) and three of the destructor (not-in-charge / in-charge / in-charge deleting).

The not-in-charge ctor and dtor are used when handling an object of a class that inherits from another class using the virtual keyword, when the object is not the complete object (so the current object is “not in charge” of constructing or destructing the virtual base object). This ctor receives a pointer to the virtual base object and stores it.

The in-charge ctor and dtors are for all the other cases, i.e. if there is no virtual inheritance involved; if the class has a virtual destructor, the in-charge deleting dtor pointer goes into the vtable slot, while a scope that knows the dynamic type of the object (i.e. for objects with automatic or static storage duration) will use the in-charge dtor (because this memory should not be freed).

Code example:

struct foo {
    virtual ~foo(void);
    int bar;

struct baz : virtual foo {
    virtual ~baz(void);

struct quux : baz {
    virtual ~quux(void);

foo::foo(int i) { bar = i; }
foo::~foo(void) { return; }

baz::baz(void) : foo(1) { return; }
baz::~baz(void) { return; }

quux::quux(void) : foo(2), baz() { return; }
quux::~quux(void) { return; }

baz b1;
std::auto_ptr<foo> b2(new baz);
quux q1;
std::auto_ptr<foo> q2(new quux);


  • The dtor entry in each of the vtables for foo, baz and quux point at the respective in-charge deleting dtor.
  • b1 and b2 are constructed by baz() in-charge, which calls foo(1) in-charge
  • q1 and q2 are constructed by quux() in-charge, which falls foo(2) in-charge and baz() not-in-charge with a pointer to the foo object it constructed earlier
  • q2 is destructed by ~auto_ptr() in-charge, which calls the virtual dtor ~quux() in-charge deleting, which calls ~baz() not-in-charge, ~foo() in-charge and operator delete.
  • q1 is destructed by ~quux() in-charge, which calls ~baz() not-in-charge and ~foo() in-charge
  • b2 is destructed by ~auto_ptr() in-charge, which calls the virtual dtor ~baz() in-charge deleting, which calls ~foo() in-charge and operator delete
  • b1 is destructed by ~baz() in-charge, which calls ~foo() in-charge

Anyone deriving from quux would use its not-in-charge ctor and dtor and take on the responsibility of creating the foo object.

In principle, the not-in-charge variant is never needed for a class that has no virtual bases; in that case, the in-charge variant is then sometimes called unified, and/or the symbols for both in-charge and not-in-charge are aliased to a single implementation.