gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) (03/08/91)
This may be all a caffeine dream, but I think that, a while back, serious consideration was being given to the idea of "virtual data". I think the idea was that a base class would define a virtual data member, and that derived classes could redefine its value. Like a virtual function, a virtual data member would be shared by all instances of a class and any derived classes that did not redefine it. Unlike static members, it would not be shared with instances of derived classes that did redefine it. This seems something like what two recent posters were asking for: >ahuttune Thu Mar 7 13:12:23 EST 1991 > >Situation: I have found that in many cases I have a base class from which >a large number of other classes have been derived. In _each_ of the derived >classes I need a piece of information that is, in a sense, identical. ... >The example that follows is usable in a game not unlike nethack, though >I am certain it can be applied to more 'serious uses'. In nethack you >don't know _exactly_ which object is which until you identify them. >The important point is that identifying _any_ object of a certain class >identifies _all_ objects of this class, but not of any other class. [His example: class Lamp with descendants NormalLamp and MagicalLamp. A Lamp* happens to point at a MagicalLamp. Identifying the thing it points at causes all MagicalLamps to be marked "identified", but has no effect on the NormalLamps.] >rosebud.llnl.gov Thu Mar 7 14:46:58 EST 1991 >I have a class that looks like: >class class_a > { > static int a_var; > int b_var; > } >This works fine except that now, it turns out, I need another set of >objects that do the exact same thing, except with a different a_var. >The only way I've been able to do this, has been to copy class_a and >rename it. I would much rather do this by using class_a as the source >for both. It seems I would need to form two subclasses or derived >classes of class_a that don't share a_var. (Sorry about the lost attribution lines.) Virtual data might also help programmers who want to implement their own type tests. My guess is that the proposal was dropped because virtual functions could provide the facility without much ugliness.
jbuck@galileo.berkeley.edu (Joe Buck) (03/10/91)
In article <1991Mar7.204853.22289@watmath.waterloo.edu>, gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) writes: [ In reference to the dungeons-and-dragons game problem where the programmer wants a static varible for each derived class ] |> Virtual data might also help programmers who want to implement their own |> type tests. |> My guess is that the proposal was dropped because virtual functions |> could provide the facility without much ugliness. Yes, let's say you want a flag associated with each class derived from class Thing, but you want a separate word for each class. You can get the effect of a virtual static data variable by using a virtual function that returns a reference. That is, class Thing : { ... virtual int& known() = 0; }; class SomeKindOfThing : public Thing { ... int& known() { static int knownFlag; return knownFlag; } }; Notice that the knownFlag static variable inside the function works very much like a virtual static class variable. This is another case that makes it appear that a more powerful template ability is needed, one that can specify how a virtual method is to be overridden in each class: you need to write the above for each derived class, because even though the function is exactly the same, the knownFlag variable is different for each class. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
jimad@microsoft.UUCP (Jim ADCOCK) (03/12/91)
In article <1991Mar7.204853.22289@watmath.waterloo.edu> gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) writes: |This may be all a caffeine dream, but I think that, a while back, serious |consideration was being given to the idea of "virtual data". I think the |idea was that a base class would define a virtual data member, and that |derived classes could redefine its value. Like a virtual function, a |virtual data member would be shared by all instances of a class and any |derived classes that did not redefine it. Unlike static members, it would |not be shared with instances of derived classes that did redefine it. Today one would do this something like: class X { static int _virt_data; public: inline virtual int& virt_data() { return _virt_data; } // or get_virt_data(), set_virt_data(int) .... }; And that's all there is to it until one implements another class that wants a distinct _virt_data. Then a programmer has to re-implement the two lines that have _virt_data's on them, or alternatively, invoke a macro hack to create the two lines from one macro. There seems to be two issues here: 1) the ugliness required to implement this each time. 2) The speed of the resulting "inline virtual" call. Issue #2 can be solved, if a particular compiler cares enough, through the use of fat tables and/or customization instead of vtables. Thus issue #2 is not a language issue, but rather a quality-of-implementation issue. Issue #1 could be solved, or at least greatly improved, if the capabilities of templates were improved to allow greater applicability to member functions. Thus, I claim its not necessary to add virtual member variables, rather we should tweak the capabilities of templates.