home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1956 < prev    next >
Encoding:
Text File  |  1993-01-02  |  3.3 KB  |  90 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: <1993Jan3.032228.14386@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> <lkc2k7INNajv@exodus.Eng.Sun.COM>
  10. Date: Sun, 3 Jan 1993 03:22:28 GMT
  11. Lines: 77
  12.  
  13. In article <lkc2k7INNajv@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes:
  14. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. >
  16. >> I would like to propose that if a class has virtual functions,
  17. >> then any destructor generated by the compiler will be virtual
  18. >> by default.
  19. >
  20. >Hmmm ... given that I've never seen such nonvirtual destructors be
  21. >anything except bug, I like the idea of fixing this problem.
  22. >
  23. >On the other hand, one of the things I'd really like to see changed is
  24. >how much stuff a C++ compiler does "for me" automagically.  It's a rare
  25. >day when it really does what I need to have done; just how often is
  26. >memory management broken when pointers "owned" by class instances are
  27. >bitwise copied?  
  28.  
  29.     A decent solution could have been had except for the
  30. extremely unfortunate (IMHO) decision that 'struct' and 'class'
  31. are synonymous (except for public/private defaults).
  32.  
  33.     For example, how about:
  34.  
  35.     generate X::X(const X&);
  36.  
  37. This could only apply to classes and not 'C' structs for compatibility
  38. reasons.
  39.  
  40. >
  41. >So, a pair of proposals that I'd be happier to see accepted:
  42. >
  43. >   (1)    It is an error for a class to have virtual functions and a
  44. >    nonvirtual destructor.
  45. >    
  46. >   (2a)    C++ compilers don't automagically generate ANYTHING for classes
  47. >    any more:  constructors, destructors, assignment and address-of
  48. >    operators, etc.  If such routines are used but not declared and
  49. >    defined, that is an error.
  50.  
  51.     Not possible for C-Structs, compiler MUST automagiocally
  52. generate constructors and assignment for these.
  53.  
  54.     Want to modify (2a) to include 'with virtual functions'?
  55.  
  56. >
  57. >Or in short, if you want to allow copying, destruction, assignment,
  58. >and so on for instances of your classes, you'll have to explicitly
  59. >provide member functions to support those actions in the interface
  60. >definitions (and implementation bodies) for your classes.
  61.  
  62.     You do NOT want to have to write the code. Explicit
  63. direction to the compiler to generate the code may be acceptable.
  64.  
  65.     generate X& operator=(const X&);
  66.  
  67. >
  68. >Perhaps the specific issues with memory management could be fixed by
  69. >the alternate proposal below:
  70. >
  71. >   (2b)    C++ compilers don't automagically generate those routines
  72. >    (complete list omitted :-) for classes that have members which
  73. >    are pointers or references.  If such routines are used but
  74. >    not declared and defined, that is an error.
  75.  
  76.     Not compatible with C.
  77.  
  78.     Personally, I'd like to ban virtual functions from
  79. 'structs' and insist structs worked as they do in C.
  80. Also allows nested structs to be globally visible, as in C.
  81.  
  82.     The classes could be distinct and have different rules.
  83. But it is too late for this.
  84.  
  85. -- 
  86. ;----------------------------------------------------------------------
  87.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  88.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  89. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  90.