Why don't we just FIX the damn vthunk problem?

[Mike Harrold]

> 
> >>>>> Jason Eager <jce2@po.cwru.edu> writes:
> 
>  > After all, it's not like a problem that hasn't been solved before...  It
>  > is a BIG problem when a compiler doesn't create valid code no matter how
>  > "obscure" the feature may be (and anyone who wants to enjoy the full
>  > benefits of C++ will probably use multiple inheritence sooner or
>  > later..
> 
> The problem only occurs if you call virtual functions from constructors of
> virtual bases, which seems a bit odd to me, but I agree it should be fixed.
> 
>  > Are there any design documents for egcs? I'll just start working on
>  > implimenting vthunks..but I'd be interested to hear about approaches
>  > that you've thought of for implimenting the vthunks....
> 
> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.
> 
> If you don't do this, you need to communicate the offset to the thunks
> somehow.  One way would be to create additional thunks on the stack that
> adjust for the appropriate offset, then jump to the old thunks.  This would
> be the most similar to gcc's non-thunk solution, but it requires support
> for putting code on the stack, like gcc trampolines.  Also, like the
> non-thunk solution, it makes constructors for objects with vbases larger
> and slower.
> 
> Another way, which Microsoft uses, is to store the offset just before the
> vbase subobject so that the thunk can find it and adjust appropriately.
> This adds a bit of space to each vbase subobject.  More importantly,

Ack! Unless I am misreading you, "a bit of space" can be very significant
when you consider word alignment, and 50000 objects, right?

> Microsoft has a patent on it, so it is not an option for us.

1) You can patent something like this? Geez...
2) I guess that makes damn sure this method doesn't get used... :P

/Mike