philip@pescadero.Stanford.EDU (Philip Machanick) (11/15/90)
In article <1990Nov13.072057.18707@Neon.Stanford.EDU>, I wrote: |> I had what I thought was a good idea for structuring a program. I had a |> class called Object at the top of the hierarchy, and my idea was that I |> would isolate low-level stuff in this layer. [stuff deleted] |> My initial attempt was to define (detail left out) |> |> class Object |> { ... static *Object free_list; ... }; |> |> What I wanted was that this static member would automatically be reinstatiated |> for each derived class. Unfortunately, this is not how things work: there is |> exactly one copy of free_list for Object and all classes derived from it. I had 2 replies on to this, one from Ralph Johnson (johnson@cs.uiuc.edu) pointing out that whqt I really wanted was class instance variables, in the style of Smalltalk, and another from Joe Pallas (pallas@alydar.Eng.Sun.COM) pointing out that the NIH library has a macro you are meant to put in every class declaration. In both cases (and in the approach I am actually using), it seems you have to put something in every class you define to get the effect I want. My understanding of the way Smalltalk works is each class is implemented as an object containing class instance variables and methods, as well as specifying what an object of that class should look like. C++ is different - a class is merely compile-time information; although static members may be referenced through a class name, this is really scoping information. Even taking this into account, would it not be possible for static data members to be a bit more like Smalltalk class instance variables (i.e., derived classes have new copies, rather than sharing static data members with base classes)? I assume this question has been looked at by the language designers. However, I believe that the use of macros in libraries like NIH (and I believe ET++) suggests there is room for improvement in the language design. If there has been a previous discussion of this on the net that I missed, I would appreciate an e-mail or 2. -- Philip Machanick philip@pescadero.stanford.edu
rpk@rice-chex.ai.mit.edu (Robert Krajewski) (11/17/90)
Hmm. At first I was thinking, ``Well, you really can't class instance variables with the current C++ model because there really isn't a run-time expression of classes in C++.'' But 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. Just a thought, mind you... ---- Robert P. Krajewski Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com
philip@pescadero.Stanford.EDU (Philip Machanick) (11/18/90)
In article <11936@life.ai.mit.edu>, rpk@rice-chex.ai.mit.edu (Robert Krajewski) writes: |> Hmm. At first I was thinking, ``Well, you really can't class instance |> variables with the current C++ model because there really isn't a |> run-time expression of classes in C++.'' But 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. |> |> Just a thought, mind you... Interesting idea. How about a new kind of class member: virtual static? -- Philip Machanick philip@pescadero.stanford.edu
roger@procase.UUCP (Roger H. Scott) (11/22/90)
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?