home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 1964 next >
Encoding:
Text File  |  1993-01-04  |  2.5 KB  |  62 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Compiler should generate virtual destructors
  5. Message-ID: <1993Jan4.154817.2032@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Dec31.050150.28929@ucc.su.OZ.AU> <C0Ayt4.263@fiu.edu>
  10. Date: Mon, 4 Jan 1993 15:48:17 GMT
  11. Lines: 49
  12.  
  13. In article <C0Ayt4.263@fiu.edu> feathers@serss0 (Michael Feathers) writes:
  14. >In article <1992Dec31.050150.28929@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. >>I would like to propose that if a class has virtual functions,
  16. >>then any destructor generated by the compiler will be virtual
  17. >>by default.
  18. >>
  19. >>(The suggestion was first read by me in a paper of Markku Sakkinen,
  20. >>who claims it was not his idea originally either.)
  21. >>
  22. >>Advantages: much safer, ensures correct deletion of objects
  23. >>by default.  Removes a source of bugs. Removes the reminder
  24. >>that its wise to do this from the FAQ.
  25. >
  26. >This would be a way in which a function within the source code would be
  27. >virtual without the keyword 'virtual' having been used on it or a function of
  28. >the same name in an inherited class.  That would bother me as a consistency 
  29. >issue.
  30.  
  31.     Yes. But it is also a way to have a virtual function which
  32. is NOT in the source code at all. Worse, it only applies
  33. if the base class already has at least one virtual function.
  34.  
  35. >
  36. >>Disadvantage: might slow down destruction a little. Can be
  37. >>fixed by the programmer explicitly declaring a non-virtual
  38. >>destructor.
  39. >
  40. >The only way to make something explicity non-virtual would be the absence
  41. >of the 'virtual' keyword, unless we add a new keyword <shudder>.
  42.  
  43.     Yes, just define a destructor in the base class without
  44. the keyword virtual.
  45. >
  46. >If the destructor is going to be made virtual by that rule, there is no
  47. >need to declare it virtual.  But we can not make it explicitly non-virtual
  48. >unless the virtual keyword is an option.
  49.  
  50.     Sure we can:
  51.  
  52.     class X { virtual fred(); } // has a virtual destructor
  53.     class Y { virtual fred(); ~Y(){} }; // non-virtual destructor
  54.  
  55. The rule only applies to compiler generated destructors.
  56.  
  57. -- 
  58. ;----------------------------------------------------------------------
  59.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  60.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  61. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  62.