Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: virtual static data? Message-ID: <54945@microsoft.UUCP> Date: 30 May 90 17:41:53 GMT References: <1990May23.102905.8689@athena.mit.edu> <13757@csli.Stanford.EDU> <54856@microsoft.UUCP> <1990May25.003734.24552@athena.mit.edu> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 57 In article <1990May25.003734.24552@athena.mit.edu> Ken Raeburn writes: >I dislike the idea of being forced to use a function call to retrieve a >piece of data that should be treated as static and virtual and const, and >_will always be simple data_. In the case I have in mind, the functions I >have to write for this class (and those derived from it) to do this will >never do anything but return this one constant value. If it were >otherwise, it would make sense to require a function, since some unforseen >new class might want to do computation to produce the results; that isn't >the case here. The only thing forcing you to use function calls to retrieve a piece of data is the fact that present day C++ compilers are not yet up to the level of quality required to really support object oriented programming. People are still trying to use C optimization techniques in C++ compilers -- the optimization issues are just not the same. Other OOPLs allow a programmer to say "foo" when either accessing a piece of data or calling a function with no parameters -- the compiler automatically handles the difference. When a programmer says "foo(bar)" a function call is [typically] made. Whether or not the methods are overridden in sub-classes. Since in C++ for versioning reasons and strict encapsulation serious programmers desire to hide whether a particular member is implemented as a member variable, or as a member function, the convention has become always use parenthesis -- C++ programmers always say "foo()" whether foo is really implemented as a function call or as an inline function short-circuiting to a member variable access. At least if "foo()" is part of the public interface. If other OOPL compilers are smart enough to optimize "foo" to mean either a variable look-up or a function call depending on the circumstances, why cannot C++ compilers be smart enough to optimize "foo()" to be either a variable look-up or a function call depending on the circumstances? [whether or not foo is virtual] -- Clearly they can! They just don't, yet. One hang up is the notion that virtual-ness needs to be handled via vtables. It needn't. Another hang- up is the traditional Unix/C model of separate compilation/linking. Without knowledge of what your children might be doing, its hard [not impossible] to avoid doing a full blown virtual function dispatch when only a "virtual static member" is needed. If a compilation/link system has complete knowledge of what children are doing, then clearly as part of a final optimized compile and link [for shipment, say] the system can say "foo() is never overridden to mean anything other than a 'virtual static member', thus I need not implement foo() as full-blown virtual function dispatches." Adding static member variables to the language would encourage people "for efficiency reasons" to make them part of the public interface. This would force designers to make hard and fast decisions between whether to offer "foo" or "foo()" as the public interface, thus constraining future choices, and leading to a constant confusion among users of classes as whether to use "foo" or "foo()" when messaging an object of this class. Let's continue to use function syntax for all public interfaces -- even though I agree it would have been nice if C hadn't already forced this convention. Let's not continue to add obscure syntax to help mediocre compilers optimize uncommon code slightly.