home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1951 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.7 KB  |  58 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Compiler should generate virtual destructors
  5. Message-ID: <9300301.307@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Dec31.050150.28929@ucc.su.OZ.AU>
  9. Date: Sat, 2 Jan 1993 14:03:43 GMT
  10. Lines: 46
  11.  
  12. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13.  
  14. >I would like to propose that if a class has virtual functions,
  15. >then any destructor generated by the compiler will be virtual
  16. >by default.
  17. >
  18. >Advantages: much safer, ensures correct deletion of objects
  19. >by default.  Removes a source of bugs. Removes the reminder
  20. >that its wise to do this from the FAQ.
  21. >
  22. >Disadvantage: might slow down destruction a little. Can be
  23. >fixed by the programmer explicitly declaring a non-virtual
  24. >destructor.
  25.  
  26. I think that this situation should cause a compiler warning, rather
  27. than adding another arbitrary rule in the language for programmers to
  28. remember. Bugs would still occur if a programmer accidentally forgot to
  29. make the destructor virtual. A good compiler will generate a warning
  30. in this situation anyway (eg. g++ does, I believe).
  31.  
  32. Mind you, I do believe that there is a place in the standard for
  33. required warnings. Claims that these are a "quality of implementation"
  34. issue ignore the social effect of standards. There are never *any*
  35. genuinely 100% conformant compilers, no matter what it says on the
  36. box you bought it in. (Read the fine print on the license inside :-( ). 
  37. The truth is that standards provide a strong incentive for compiler
  38. vendors to ship products with certain characteristics. Provided (as
  39. with all other aspects of a standard) that they don't require an
  40. excessive difficulty of implementation, I don't see any good reason
  41. not to include particular required warnings as part of a standard.
  42.  
  43. [Off the topic, another situation that should have a required warning
  44. is the (void *) to (T *) conversion. It is definitely a hole in the
  45. type system, but making such conversion *illegal* breaks many C programs.
  46. It broke ALL of my C programs (well, ok, except for the hello world ones :-).
  47. A warning would have closed the hole in the type system just as well -
  48. after all, programmers can always achieve the same effect with a cast,
  49. so it doesn't actually "close" the hole anyway - the error message is
  50. just like a warning, except that you have to actually modify the
  51. program text to get it to compile.]
  52.  
  53. -- 
  54. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  55. This .signature virus is a self-referential statement that is true - but 
  56. you will only be able to consistently believe it if you copy it to your own
  57. .signature file!
  58.