Can I have Pure Virtual Destructor?
in [C++]
|
From: peter koch larsen on 8 Mar 2007 20:50 On 9 Mar., 11:18, Gerhard Menzl <clcppm-pos...(a)this.is.invalid> wrote: > 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? > I am not sure I understand you. What is wrong with making the destructor non-pure and thus work with a base class that is not abstract? /Peter [snip] -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 8 Mar 2007 20:46 On Mar 8, 6:44 pm, "norbert.ried...(a)web.de" <norbert.ried...(a)web.de> wrote: > > > 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. > is that true? No. I made a mistake. I don't know why I thought this, but I always had, without actually verifying it (either in the standard, or with compilers). > I mean, every class not declaring a destructor, declares > and defines it implicitly. Correct. And that implicit declaration is never pure virtual, and suffices to make the derived class concrete. I don't know what put any other idea into my head (but whatever it was, I should have verified it). -- James Kanze (GABI Software) email:james.kanze(a)gmail.com Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nicola Musatti on 9 Mar 2007 01:28 On Mar 6, 9:25 pm, Sebastian Redl <e0226...(a)stud3.tuwien.ac.at> wrote: [...] > Note that you can still provide an implementation even if the destructor > is pure virtual. Actually you *must* provide an implementation for a pure virtual destructor if you want to instantiate any of its class's descendents. See 12.4(7) in the standard. Cheers, Nicola Musatti -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gerhard Menzl on 11 Mar 2007 18:45 peter koch larsen wrote: > I am not sure I understand you. What is wrong with making the > destructor non-pure and thus work with a base class that is not > abstract? That's simple: you don't want abstract state objects to be instantiated, as they would be dead ends from which no transition can make you escape. What is wrong with making the destructor pure and have the compiler prevent it? -- 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! ]
From: peter koch larsen on 12 Mar 2007 01:46
On 12 Mar., 10:45, Gerhard Menzl <clcppm-pos...(a)this.is.invalid> wrote: > peter koch larsen wrote: > > I am not sure I understand you. What is wrong with making the > > destructor non-pure and thus work with a base class that is not > > abstract? > > That's simple: you don't want abstract state objects to be instantiated, > as they would be dead ends from which no transition can make you escape. > What is wrong with making the destructor pure and have the compiler > prevent it? But is that not primarily a question of documentation? Having a pure virtual destructor is no hint as to what functions to override. If you want to prevent the class from being instantiated, you could instead have protected constructors and this is IMHO a cleaner approach (although my reading elsewhere in this thread implies that the virtual destructor trick does not require you to implement the destructor in the derived class - essentially making this entire discussion void). /Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |