Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!mips!atha!aunro!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!ubc-cs!uw-beaver!ssc-vax!bcsaic!mgates From: mgates@entiat.boeing.com (Michael Gates) Newsgroups: comp.lang.c++ Subject: Re: private inheritance in G++ 1.39 Message-ID: Date: 28 Jun 91 20:59:53 GMT References: <1991Jun27.163527.25117@lynx.CS.ORST.EDU> Sender: news@bcsaic.UUCP Organization: Boeing Computer Services, Bellevue, WA Lines: 39 In-reply-to: budd@fog.cs.orst.edu's message of 27 Jun 91 16:35:27 GMT In article <1991Jun27.163527.25117@lynx.CS.ORST.EDU> budd@fog.cs.orst.edu (Tim Budd) writes: > We've recently upgraded our g++ from 1.37 to 1.39. I have some code that > used to work that now gives errors. So now I'm wondering if it is g++ 1.39 > that is at fault or if my reading of ARM 11.2 and 11.3 is wrong. > The problem involes private inheritance. Now it makes sense that when you > inherit privately from a base class that defines a destructor you need to > also make the destructor public in the subclass. The following example > worked fine in 1.37, but complains about *both* the declarations now. > (error message is ``type Two is derived from private One'' - a most > uninformative error message since it tells me exactly what I already knew > and what I wanted in any case. > > class One { > public: > one() {printf("in one \n"); } > ~One() {} > }; > > class Two : private One { > public: > two() { printf("in two\n"); } > One::~One; > }; Destructors are not inherited. Also, if a destructor is not declared for a class inheriting from a base that does declare one, then a default destructor is generated. Since that creates a function in the derived class with the same name as the one in the base class, the inherited one cannot have it's access adjusted. Illegal two ways, though the compiler message certainly is not helpful. The default destructor generated for the derived class calls the base class destructor, and it is public. So to accomplish what you want, just remove the One::~One; line. This from ARM 12.4, pp 276 and 277 (also the sections named above). -- et tu mgates?