Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!tdatirv!sarima From: sarima@tdatirv.UUCP (Stanley Friesen) Newsgroups: comp.lang.c++ Subject: Re: Efficient compilation of virtual functions Message-ID: <135@tdatirv.UUCP> Date: 28 Aug 90 15:48:35 GMT References: <1990Aug22.193347.18486@ux1.cso.uiuc.edu> <6428@wolfen.cc.uow.oz> <417@taumet.com> Reply-To: sarima@tdatirv.UUCP (Stanley Friesen) Organization: Teradata Corp., Irvine Lines: 20 In article amanda@iesd.auc.dk (Per Abrahamsen) writes: >Stephen> How do you know that another object with slightly more specialized >Stephen> behavior will never be needed in the future? >In my programs, such a situation would indicate the need for a new >abstract class, which provided the functionality shared by both >classes. This is quite fine for a situation where the whole project is being done in one organization. It fails big where a large part of the project is in the form of libraries from other groups. In order to introduce a new abstract class above an existing class, the source code to the leaf class is required, so it can be recoded as a derived class of the new base class. (Note this requires modification of the implementation of the leaf class). So, if you want to do this, do NOT ever put such a leaf class in a library that is distributed to anyone else. This way the users of the libarary will not be limited in how they use it, by being required to duplicate its functionality elsewhere.