Re: Understanding branches within destructors
On Oct 24, 8:12 pm, Jeff Newman <Jeffrey.M.New...@gmail.com> wrote:
The branches are most likely part of the virtual function dispatch
code that gcc put in the destructor. My understanding is that
compilers may locate virtual function dispatch code wherever they
want, and gcc chooses to put in in the function itself, at least in
the case of a virtual destructor.
What style of call would then result in taking the other branches?
I've tried the following (which is all the cases I can think of), and
there are still unexecuted branches.
struct blah
{
blah() {};
virtual ~blah()
{
};
};
struct derived : blah
{
derived() {};
~derived() {};
};
int main()
{
blah myBlah;
blah* myDerived = new derived();
delete myDerived;
derived myDerived2;
return 0;
}
The (snipped) report:
3: 4: virtual ~blah()
3: 5: {
3: 6: };
branch 0 never executed
branch 1 never executed
call 2 never executed
branch 3 taken 0 (fallthrough)
branch 4 taken 2
call 5 never executed
branch 6 taken 0 (fallthrough)
branch 7 taken 1
call 8 never executed
-: 7:};
It's most likely (given that you're using GCC) that it instantiates
two destructors - one for if it is a non-virtual base class (which
means that it calls its parent destructors) and when it is (which
means that it does not call its parent destructors). Your virtual
function table contains two functions too.
If it's nonvirtual it should still generate both of them, but it might
notice that it has no base classes and that they are equal, and hence
merge them. It also might not generate one of them as nobody calls it.
In case of virtual functions, somebody outside of your scope of
compilation might call it anyway, so it has to generate it and put it
in the virtual function table - so it has to be made, and then has
uncalled code.
Could you try the test again using it as a virtual base in one
subclass?
Regards,
Peter