From 4286606461920970338 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8c9f1307b83ac2db X-Google-Attributes: gidf78e5,public From: "Cristian Georgescu" Subject: Re: Q: virtual functions not overridable anymore? Date: 1997/09/10 Message-ID: <5v54g1$id@bgtnsc03.worldnet.att.net>#1/1 X-Deja-AN: 271380286 References: <01bcb109$1e790180$433574cf@worldnet.worldnet.att.net> <3404A0AE.6F7E@Eng.Sun.COM> X-Original-Date: 10 Sep 1997 03:34:25 GMT Organization: Opal Technologies X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNBbu70y4NqrwXLNJAQF8IwH8D1uRP6SJ8sG+N8u1vabKOmE/C16xBv3k Fvjq4f/nmAK4p/8ym+mkcu70cZPw3pmEwRh3g1Qr+oETA/jKLZ7+4A== =Z9q1 Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com > I've always thought this was an unfortunate hole in the access rules, > because of this awkward situation: > > class A { some virtual members }; > class B : private A { ... }; > class C : public B { ... }; > > The author of C needs to be aware of B's inheritance from A, and needs to > know the virtual functions of A, so that C won't accidentally override > them. Likewise, one cannot add a private base class to B without the danger > that a formerly non-virtual member of C will become virtual, or be called > at unexpected times. > --Tom Lippincott I fully agree: IMO the logical encapsulation of a class should consist in the separation of the class interface from the class implementation: the user should be able to use the class by looking only to the public and to the private parts of the class; he should not be obliged to peep to the private parts of the base class in order to use the class. C++ does not achieve very well this logical encapsulation; the .h files are obliged to contain the private parts as well: in order to fully specify the class storage. > A comment in the ARM (11.6) suggests: > > Private virtual functions provide a way for the implementation of a > > base class to rely on derived classes without the functions involved > > being exposed to the general users of the base class. What is worse is that usually the private parts of a base class are considered "Implementation" details; and therefore they are supposed to change. If the client bases the code on the use of a private virtual base class function (by overridding it) then when this function will change (as it may be because the function is private) then the end of the world comes (for the user): user code has to change! In my opinion what ARM (11.6) suggests as possible, should never be used. > I haven't been able to come up with an example along these lines > which isn't adequately served by making the virtual function protected. > > --Tom Lippincott I fully agree with this also; Probably overriding private virtual functions should be banished from the language. In fact I would go even further, I would interdict the declaration of the virtual functions in the private part of the class: virtual functions should be allowed in the protected and public part of a class only! -- Cristian Georgescu _________________________________________________ Smith Industries Aerospace & Defense Systems 7-9 Vreeland Road, Florham Park, NJ 07932, USA. _________________________________________________ E-mail: Georgescu_Christian@si.com E-mail: Cristian.Georgescu@worldnet.att.net --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]