home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1954 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  3.0 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ames!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!argon.Eng.Sun.COM!db
  2. From: db@argon.Eng.Sun.COM (David Brownell)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Compiler should generate virtual destructors
  5. Date: 2 Jan 1993 21:35:03 GMT
  6. Organization: SunSoft
  7. Lines: 64
  8. Message-ID: <lkc2k7INNajv@exodus.Eng.Sun.COM>
  9. References: <1992Dec31.050150.28929@ucc.su.OZ.AU>
  10. NNTP-Posting-Host: argon
  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. Hmmm ... given that I've never seen such nonvirtual destructors be
  19. anything except bug, I like the idea of fixing this problem.
  20.  
  21. On the other hand, one of the things I'd really like to see changed is
  22. how much stuff a C++ compiler does "for me" automagically.  It's a rare
  23. day when it really does what I need to have done; just how often is
  24. memory management broken when pointers "owned" by class instances are
  25. bitwise copied?  Arguments I've heard against automagic generation of 
  26. code by the C++ compiler seem to fall into three categories:
  27.  
  28.     -    Memory management bugs get trivially introduced, both in the
  29.     initial implementations and during subsequent maintainence;
  30.  
  31.     -    Declaring automagic routines as 'private', with implementations
  32.     that abort, to prevent assigning/copying data structures that
  33.     shouldn't be support those operations (due to various expenses,
  34.     or to design desiderata) is really ugly, and consumes both
  35.     coding and runtime resources;
  36.  
  37.     -    It's confusing both to beginning and to expert programmers
  38.     (e.g. C ones who are "upgrading" to C++) that private data
  39.     structures be manipulated (and bugs added) by compilers.
  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. Or in short, if you want to allow copying, destruction, assignment,
  52. and so on for instances of your classes, you'll have to explicitly
  53. provide member functions to support those actions in the interface
  54. definitions (and implementation bodies) for your classes.
  55.  
  56. Perhaps the specific issues with memory management could be fixed by
  57. the alternate proposal below:
  58.  
  59.    (2b)    C++ compilers don't automagically generate those routines
  60.     (complete list omitted :-) for classes that have members which
  61.     are pointers or references.  If such routines are used but
  62.     not declared and defined, that is an error.
  63.  
  64. Existing code compiled with a compiler enforcing (2a) or (2b) would
  65. generate error messages; fixing that code and then recompiling it with
  66. today's compilers (e.g. CFRONT) would not cause any problems at all.
  67.  
  68. Comments?
  69.  
  70. - Dave
  71.  
  72. --
  73. David Brownell                        db@Eng.Sun.COM.
  74. Distributed Object Management
  75.  
  76.