Can I have Pure Virtual Destructor?
in [C++]
|
From: Francis Glassborow on 7 Mar 2007 22:01 In article <b5f29$45eeaedb$1860878d$6215(a)KNOLOGY.NET>, "Dennis (Icarus)" <ala_dir_diver(a)yahoo.com> writes >"Val" <valosmith(a)gmail.com> wrote in message >news:1173196295.237848.323320(a)s48g2000cws.googlegroups.com... >> >> This is talked about in detail in Item 14 of "Effective C++" by >> Meyers. >> >> You can't have a pure virtual destructor if the compiler is following >> the language spec. If you were to derive a concrete class from the >> abstract one, then create and destroy an object, the base class's >> destructor would be invoked immediately before the derived >> destructor. If the base destructor isn't implemented, then this is a >> problem. > >I thought that destructors of derived classes were invoked before those of >base classes? They are, but destructors automatically chain. When the body of a dtor completes its final act is to 'call' the dtor of the base(s) Val got it the wrong way round, however there must be an implementation of every explicit dtor. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: norbert.riedlin on 8 Mar 2007 00:44 > > No, making a function a pure virtual does not prevent you from > > implementing it. All it does is to require that ever derived concrete > > class has an implementation (possibly inherited from an intermediate > > derived class) > > That's right, but maybe a bit confusing. What it means is that > until at least one class on a direct path from the most derived > class to the base class has a user declared (and defined) > destructor, the class is abstract, and cannot be instantiated. > What declaring the destructor pure virtual does, in practice, is > to require every derived class to provide a user defined > destructor, even when it wouldn't need one otherwise. Hi, is that true? I mean, every class not declaring a destructor, declares and defines it implicitly. And that should also be the case with a class deriving from a class declaring a pure virtual destructor, isn't it? The following code compiles fine with gcc version 4.0.2 and comeau's online compiler and seems to support my guess: <code> struct test1 { public: virtual ~test1()=0; }; test1::~test1() {} struct test2:test1 { }; test2 t2; </code> Does anyone know what the standard has to say in this regard? Bye Norbert -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: red floyd on 8 Mar 2007 05:16 norbert.riedlin(a)web.de wrote: > > <code> > > struct test1 { > public: > virtual ~test1()=0; > }; > test1::~test1() > {} > > struct test2:test1 { > }; > > test2 t2; > > </code> > > Does anyone know what the standard has to say in this regard? > That code is perfectly fine, and exactly what you need to do. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Sebastian Redl on 8 Mar 2007 05:16 On Thu, 8 Mar 2007, norbert.riedlin(a)web.de wrote: > > > > What declaring the destructor pure virtual does, in practice, is > > to require every derived class to provide a user defined > > destructor, even when it wouldn't need one otherwise. > > Hi, > > is that true? I mean, every class not declaring a destructor, declares > and defines it implicitly. And that should also be the case with a > class deriving from a class declaring a pure virtual destructor, isn't > it? > > Does anyone know what the standard has to say in this regard? > Not much. 12.4 talks about destructors. Paragraph 3 is about the implicit declaration, paragraph 5 about the implicit definition. Paragraph 7 says that destructors can be virtual and even pure virtual, and that if the destructor of any base class is virtual, that of the derived class is too, whether implicit or user-defined. 10.4 talks about abstract classes; however, no special mention of destructors is made. 10.3 talks about virtual functions in general. Paragraph 4 in particular mentions that derived destructors override base destructors. It seems that the standard does not differ between implicit and explicit destructors in general, so I would say you are correct: an implicit destructor is a valid override for a pure virtual destructor and the class therefore instantiable. Sebastian Redl -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gerhard Menzl on 8 Mar 2007 17:18
peter koch larsen wrote: > So if I understand you correctly, you use the virtual destructor as a > hint that other functions are virtual with a "questionable" default > implementation? This is silly. If anything, this behaviour requires an > implicit understanding which should be given in a better way than by > requiring the implementor to write an empty destructor. Let me expand a concrete example I have given in another posting. Think of the GoF state pattern and a state machine with seven states and twenty requests. The greater part of the cells in the resulting matrix of 140 handlers is empty, i.e. most states react on a few selected stimuli (but each state on a different set of them) and do nothing when receiving the others. Now which is the sillier way to implement this: insisting on the mantra that pure virtual destructors are useless, make the base class handlers pure virtual, and force derived classes to implement several dozens of empty functions in total, or implement 21 no-ops (20 handlers and one pure virtual destructor) once in the base class and make derived classes react only to those requests that they actually need to handle? You could still argue that writing all those empty overrides is justified for reasons of documentation, maintainability, locality of reference, symmetry, consistency, beauty and whatnot. But your argument of avoiding gratuitous typing just does not hold. As I said, this is not exactly an everyday scenario, at least for most problem domains, but when you encounter it (it happened to me once or twice), you are glad that C++ doesn't get in your way like certain languages the designers of which were so confident of their prescience that they banned every feature (or combination of features) they were certain nobody would or, for that matter, should need. -- Gerhard Menzl Non-spammers may respond to my email address, which is composed of my full name, separated by a dot, followed by at, followed by "fwz", followed by a dot, followed by "aero". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |