This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
>>>>> 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, Microsoft has a patent on it, so it is not an option for us. Any other ideas? Jason