in-charge constructors and destructors of abstract classes

in-charge constructors and destructors of abstract classes

[Roman Zybin]

The main idea was to prove that there shouldn't be dependency on
in-charge constructors and destructors of an abstract classes (since
there is no need for their invokations during inheritance), but there
is such dependency for QGList class from qt3. The example below only
represents QGList structure.

Consider the following example:
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)

myclass.h:

#ifndef MYCLASS_H
#define MYCLASS_H

class Myclass
{
public:
        virtual int a();
        virtual int b();
};

inline int Myclass::a()
{
    return 1;
}

#endif

myclass.cpp:

#include "myclass.h"
        
int Myclass::b()
{
    return 2;
}

test.cpp:

#include "myclass.h"

int main()
{
    return 0;
}

Makefile:

gcc -fPIC -c myclass.cpp
gcc -shared -o libmyclass.so myclass.o
gcc -c test.cpp
gcc test.o -L. -lmyclass -o test


There is the dependency on Myclass::b() method whereas it isn't
needed at all. And on binary level we see just reference but no another
usage.

Relocation section '.rela.plt' at offset 0x658 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000500c30  000100000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main + 0
000000500c38  000300000007 R_X86_64_JUMP_SLO 00000000004006d8 _ZN7Myclass1bEv + 0
000000500c40  001000000007 R_X86_64_JUMP_SLO 00000000004006e8 __gxx_personality_v0 + 0

test.asm:
00000000004006d8 <_ZN7Myclass1bEv@plt>:
  4006d8:       ff 25 5a 05 10 00       jmpq   *1049946(%rip)        # 500c38 <_GLOBAL_OFFSET_TABLE_+0x20>
  4006de:       68 01 00 00 00          pushq  $0x1
  4006e3:       e9 d0 ff ff ff          jmpq   4006b8 <_init+0x18>

The example has also been tested on gcc (GCC) 4.2.3 (Debian 4.2.3-1) with similar
output.

So, questions:
1. Is the situation described above regarded as normal or it is just a bug?
2. Are in-charge constructors and destructors of abstract classes really not needed anywhere?
3. If so, should compiler not include them into its output?


Regards,
Roman