home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1958 < prev    next >
Encoding:
Text File  |  1993-01-03  |  2.6 KB  |  71 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!dpg
  3. From: dpg@extro.ucc.su.OZ.AU (D P Gilbert)
  4. Subject: Re: Compiler should generate virtual destructors
  5. Message-ID: <dpg.726062785@extro.ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: Sydney University Computing Service, Sydney, NSW, Australia
  9. References: <1992Dec31.050150.28929@ucc.su.OZ.AU> <lkc2k7INNajv@exodus.Eng.Sun.COM> <1993Jan3.032228.14386@ucc.su.OZ.AU>
  10. Date: Sun, 3 Jan 1993 12:06:25 GMT
  11. Lines: 58
  12.  
  13. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  14.  
  15. >In article <lkc2k7INNajv@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes:
  16. >>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  17. >>
  18. >>> I would like to propose that if a class has virtual functions,
  19. >>> then any destructor generated by the compiler will be virtual
  20. >>> by default.
  21. >>
  22. >>Hmmm ... given that I've never seen such nonvirtual destructors be
  23. >>anything except bug, I like the idea of fixing this problem.
  24. >>
  25. >>On the other hand, one of the things I'd really like to see changed is
  26. >>how much stuff a C++ compiler does "for me" automagically.  It's a rare
  27. >>day when it really does what I need to have done; just how often is
  28. >>memory management broken when pointers "owned" by class instances are
  29. >>bitwise copied?  
  30.  
  31. >    A decent solution could have been had except for the
  32. >extremely unfortunate (IMHO) decision that 'struct' and 'class'
  33. >are synonymous (except for public/private defaults).
  34.  
  35. >    For example, how about:
  36.  
  37. >    generate X::X(const X&);
  38.  
  39. >This could only apply to classes and not 'C' structs for compatibility
  40. >reasons.
  41.  
  42. >>
  43. >>So, a pair of proposals that I'd be happier to see accepted:
  44. >>
  45. >>   (1)    It is an error for a class to have virtual functions and a
  46. >>    nonvirtual destructor.
  47. >>    
  48. >>   (2a)    C++ compilers don't automagically generate ANYTHING for classes
  49. >>    any more:  constructors, destructors, assignment and address-of
  50. >>    operators, etc.  If such routines are used but not declared and
  51. >>    defined, that is an error.
  52.  
  53. >    Not possible for C-Structs, compiler MUST automagiocally
  54. >generate constructors and assignment for these.
  55.  
  56. >
  57. >         Want to modify (2a) to include 'with virtual functions'?
  58. > ......
  59.  
  60. How about a new keyword "__pure" to
  61.     1)    prefix "class" in a class definition to stop automagic
  62.         constructor + assignment generation ++
  63.     2)    prefix "virtual" in a pure virtual function
  64.         declaration to get rid of the "=0" hack
  65.     3)    waste some of the compiler implementor's name space
  66.         (rather the the compiler user's name space). The
  67.         user can #define pure __pure if it causes no problem
  68.  
  69.  
  70. Doug Gilbert
  71.