Can I have Pure Virtual Destructor?
in [C++]
|
From: Gerhard Menzl on 12 Mar 2007 22:07 peter koch larsen wrote: > But is that not primarily a question of documentation? Having a pure > virtual destructor is no hint as to what functions to override. Everyone familiar with the GoF State pattern will not need more than a cursory glance to find out which functions to override. Documentation is essential, but I prefer documentation which the compiler can enforce. > If you want to prevent the class from being instantiated, you could > instead have protected constructors and this is IMHO a cleaner > approach Cleaner in what sense? The pure-specifier (= 0) is about the most idiomatic and direct way to express the designers intention that a class is not to be instantiated. Actually, this is its very purpose. > (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). I don't know how the idea arose. If it were true, I doubt I ever would have used a pure virtual destructor. The entire discussion would probably never have started if C++ had a less clumsy and implementation-inspired way to declare a class abstract, such as "abstract class ...". -- 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 13 Mar 2007 08:05 On 13 Mar., 14:07, Gerhard Menzl <clcppm-pos...(a)this.is.invalid> wrote: > peter koch larsen wrote: > > But is that not primarily a question of documentation? Having a pure > > virtual destructor is no hint as to what functions to override. > > Everyone familiar with the GoF State pattern will not need more than a > cursory glance to find out which functions to override. Documentation is > essential, but I prefer documentation which the compiler can enforce. I certainly agree here. > > > If you want to prevent the class from being instantiated, you could > > instead have protected constructors and this is IMHO a cleaner > > approach > > Cleaner in what sense? The pure-specifier (= 0) is about the most > idiomatic and direct way to express the designers intention that a class > is not to be instantiated. Actually, this is its very purpose. As I hinted to in my previous post, this was based on my misconception that the destructor in a derived class would need a userdefined destructor. Now that it is clear that this is not the case, I agree with you that the pure virtual is the way to go. > > > (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). > > I don't know how the idea arose. If it were true, I doubt I ever would > have used a pure virtual destructor. Neither do I. I have just always thought that to be the case. And I believe it to be the case for all other virtual functions. Apparantly, I'm not alone here as Francis Glassborow and James Kanze both had the same weird idea. Nice to be in good company ;-) > > The entire discussion would probably never have started if C++ had a > less clumsy and implementation-inspired way to declare a class abstract, > such as "abstract class ...". Or just some documentation. After all, the destructor is the only virtual function the compiler will auto-generate, so a note somewhere would have been nice. And perhaps the note is there somewhere, and I have simply forgotten about the fact. /Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 14 Mar 2007 05:31 In article <1173798799.278082.275810(a)c51g2000cwc.googlegroups.com>, peter koch larsen <peter.koch.larsen(a)gmail.com> writes >> > (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). >> >> I don't know how the idea arose. If it were true, I doubt I ever would >> have used a pure virtual destructor. > >Neither do I. I have just always thought that to be the case. And I >believe it to be the case for all other virtual functions. Apparantly, >I'm not alone here as Francis Glassborow and James Kanze both had the >same weird idea. Nice to be in good company ;-) Excuse me, I do not think that either I or James thought what you seem to think we did. What we said was that it was necessary to provide an implementation of the pure virtual dtor for the _abstract_base_class_. I am certain that James knows just as well as I do that the dtor in a derived class might be implicitly declared and defined. -- 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: James Kanze on 15 Mar 2007 03:33 On Mar 14, 9:31 pm, Francis Glassborow <fran...(a)robinton.demon.co.uk> wrote: > In article <1173798799.278082.275...(a)c51g2000cwc.googlegroups.com>, > peter koch larsen <peter.koch.lar...(a)gmail.com> writes > >> > (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). > >> I don't know how the idea arose. If it were true, I doubt I ever would > >> have used a pure virtual destructor. > >Neither do I. I have just always thought that to be the case. And I > >believe it to be the case for all other virtual functions. Apparantly, > >I'm not alone here as Francis Glassborow and James Kanze both had the > >same weird idea. Nice to be in good company ;-) > Excuse me, I do not think that either I or James thought what you seem > to think we did. What we said was that it was necessary to provide an > implementation of the pure virtual dtor for the _abstract_base_class_. > I am certain that James knows just as well as I do that the dtor in a > derived class might be implicitly declared and defined. Well, I do now:-). But for I don't know what reasons, I had thought that it had to be user defined. It's doubtlessly one of those things that I mislearned at the very beginning, and have never had the occasion until this thread to reconsider. It was only when I started to write my second posting saying the same thing that it occurred to me that it was a wierd rule---that in every other case, the compiler generated default acted exactly like a user defined version---and so tried it out, and found out that I was wrong. (Embarassingly, the first posting had already been accepted, so I can't just pretend I always knew:-).) -- 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! ]
First
|
Prev
|
Pages: 1 2 3 4 5 6 7 Prev: class template syntax, maybe? Next: Using SFINAE with member function types |