Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!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: Efficient compilation of virtual functions Message-ID: <56971@microsoft.UUCP> Date: 27 Aug 90 21:18:29 GMT References: <1990Aug22.193347.18486@ux1.cso.uiuc.edu> <6428@wolfen.cc.uow.oz> <417@taumet.com> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 39 In article <417@taumet.com> steve@taumet.com (Stephen Clamage) writes: |amanda@iesd.auc.dk (Per Abrahamsen) writes: | ||>>>>> On 22 Aug 90 23:40:48 GMT, pejn@wolfen.cc.uow.oz (Paul Nulsen) said: | ||Paul> The problem then is that the compiler needs to know that subclass has ||Paul> nothing derived from it. This is not possible with separate compilation. | ||It would be nice to be able to declare a class or even a member ||function as "leaf". Even if we disregard the possible optimizations, ||it would add to the programmers ability to document the classes. | |I don't think I agree with this. If you declared a leaf node, you |would be prohibiting further reuse of the class by deriving from it. |How do you know that another object with slightly more specialized |behavior will never be needed in the future? | |Someone needing this capability while also using your code would be |required to duplicate the existing code with new names, then create |conversion functions to your old class hierarchy. This seems like a |steep price to pay for some special-case micro-optimization. C++ already provides a way for a class designer to prevent others from deriving from it: Just make the constructors private. Given that C++ already gives class designers the right to specify that no class can be derived from a given class, should compilers be allowed to optimize on that class's leaf-ness? Should there be a friendlier way to specify leaf-ness rather than have to specify constructors private? --- Besides leaf-ness, there are other good reasons why a class designer might want to prohibit direct derivation. For example, it might be known that the base class's member variable list might not be very stable, so that it is desirable to be able to change the size of the base class without recompiling all the subclasses. At the cost of a new, and a pointer- indirection, the derived class can inherit from a reference-to-the-base-class class, maintaining identical usage syntax, but allowing the size of the base class implementation to grow without recompiling the derived classes.