Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!procase!roger
From: roger@procase.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: Class instance variables (was Re: inheriting statics)
Message-ID: <203@c.procase.UUCP>
Date: 21 Nov 90 20:53:25 GMT
References: <1990Nov13.072057.18707@Neon.Stanford.EDU> <1990Nov14.212657.5671@Neon.Stanford.EDU> <11936@life.ai.mit.edu>
Reply-To: roger@procase.UUCP (Roger H. Scott)
Organization: proCASE Corporation, Santa Clara, CA
Lines: 13

In article <11936@life.ai.mit.edu> rpk@rice-chex.ai.mit.edu (Robert Krajewski) writes:
>... if you have any virtual
>functions in a class, there *is* a per-class thing that lives at
>run-time -- its table of virtual functions.  So maybe one could
>overload (!) the Vtable concept, and use negative offsets to the
>VTable pointer for class instance variables, and then just add
>inherited class instance variables before the superclass.
No need for anything so elaborate.  Just allocate regular vtbl slots for
the *addresses* of "virtual static data members" (a.k.a. class instances
variables) in the same way that you allocate slots for the addresses of
virtual functions.  The only objection I have heard to this plan is that it
leaves an ugly hole in the semantic paradigm for "virtual non-static data
members" - what would they mean?