Construction vtables

[Martin von Loewis]

> I think only condition 1 applies.  If base class accesses its
> virtual bases during construction, the offsets in the virtual base
> part of the vtable will be wrong if it's part of a more derived
> class with a different layout.

Right. I was still assuming vbase pointers in the object (which g++
currently does), and forgetting that vbase offsets are in the vtable.

> Doesn't the ABI spec call for complete object ctor/dtors which would
> create the VTT and subobject ctors/dtors that recieve the VTT in their
> argument list?

What do you mean by 'create'? Dynamically, at run-time? I hope not.
The VTTs should be emitted statically according to some rule (probably
together with the vtables), and would get a certain external mangled
name. Also, constructors and destructors in classes with VTTs would
have a second implicit parameter (after this), which is the VTT
pointer.

My question is what the calling convention for destructors is. It
can't be 'caller passes VTT pointers', considering

struct Base{
  virtual ~Base();  //Base::~Base does not take VTT
};

struct Derived:virtual Base{
  ~Derived();  //~Derived does expect VTT
};

int main(){
  Base *b = new Derived;  // compiler may know to pass __VTT__Derived
  delete b;               // compiler cannot know to what VTT to pass
}

I think it must be specified what the caller passes in the VTT. Here
is my proposal, again:

  The caller passes 0 to as the VTT parameter of a constructor of a
  class with a VTT. It always passes 0 to the destructor, no matter
  whether the class has a VTT or not.

That way, a dtor in a class with VTT would look like this

Derived::~Derived(vtable **VTT){
  if (VTT==0) VTT = __VTT__Derived;
  this->vptr = VTT[0];
  ...
}

The alternative is that the caller passes the right VTT always, which
means that there need to be two destructor entry points in case of
virtual destructors.

Regards,
Martin