Covariant polymorphic returns and when sharing B-D V-pointers

[Jason Merrill]

The alternative I was talking about yesterday goes something like this:

When we have a non-trivial covariant return situation, we create a new
entry in the vtable for the new return type.  The caller chooses which
vtable entry to use based on the type they want.

This could be implemented several ways, at the discretion of the vendor:

1) Multiple entry points to one function, with an internal flag indicating
   which type to return.
2) Thunks which intercept the function's return and modify the return
   value.  Note that unlike the case of calling virtual functions, for
   covariant returns we always know which adjustments will be needed, so we
   don't have to pay for a long branch.  We do, however, lose the 1-1
   correspondence between calls and returns, which apparently affects
   performance on the Pentium Pro.
3) Function duplication.

The advantage of this approach to the complex case is that we don't have to
do a dynamic_cast when faced with multiple levels of virtual derivation.
It is also strictly simpler; Daveed's model already requires something like
this in cases of multiple inheritance.

Of course, we can always mix and match; we could choose to only do this in
cases of virtual inheritance, or use Daveed's proposal and do this only in
cases of repeated virtual inheritance.  In that case, the multiple returns
would just be an optimization for the single virtual inheritance case.

Since we don't seem to care about the performance of anything but single
nonvirtual inheritance, it seems simpler not to bother with multiple
returns.

The remaining question is how to handle the case of nontrivial nonvirtual
inheritance: do we use multiple slots or have the caller do the adjustment?
My inclination is to have the caller adjust.

WRT patents, the idea of having the function return the base-most class and
having the caller adjust is parallel to the patented Microsoft scheme
whereby they pass the base-most class as the 'this' argument to virtual
functions, but the word 'return' does not appear anywhere in the patent, so
it seems safe.

Jason