home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13309 < prev    next >
Encoding:
Text File  |  1992-09-07  |  1.9 KB  |  69 lines
  1. Path: sparky!uunet!sun-barr!cs.utexas.edu!devnull!rgp
  2. From: rgp@mpd.tandem.com (Ramon Pantin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Destructors and exit()
  5. Message-ID: <2384@devnull.mpd.tandem.com>
  6. Date: 4 Sep 92 19:08:12 GMT
  7. References: <1992Sep3.220301.16983@murdoch.acc.Virginia.EDU> <rmartin.715615353@thor>
  8. Sender: news@devnull.mpd.tandem.com
  9. Organization: Tandem Computers, Micro-Products Division
  10. Lines: 57
  11.  
  12. In article <rmartin.715615353@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  13. >main()
  14. >{
  15. >  MyClass A;
  16. >  static MyClass B;
  17. >
  18. >  exit();
  19. >}
  20. >
  21. >
  22. >The destructor for B should be invoked.  But the destructor for A
  23. >probably will not.  I say probably, because a clever compiler might be
  24. >able to figure out that, upon exit, the enclosing stack frames should
  25. >be destroyed.
  26.  
  27. IMHO, it would be incorrect for a compiler to "know" anything about
  28. exit (exit is part of the C library, not part of the language, "exit"
  29. is not a keyword).  A call to the exit function has never triggered
  30. destructions of automatic objects and should never do.  The block where
  31. the object was constructed is not being exited when the exit function
  32. is called so it is incorrect to destroy the object.  Doing so would
  33. invalidate valid code such as:
  34.  
  35.     #include <stdlib.h>
  36.     class A {
  37.         A() { ... };
  38.         ~A() { ... };
  39.     };
  40.     A    *ap;
  41.     cleanup()
  42.     {
  43.         if (ap)
  44.             ap->cleanup();
  45.     }
  46.     main()
  47.     {
  48.         A    a;
  49.         atexit(cleanup);
  50.         if (...)
  51.             exit(1);
  52.         ...
  53.         ap = &a;
  54.         ...
  55.         exit(1);
  56.     }
  57.  
  58. Or some other code where the destruction of the automaitc object has side
  59. effects that are observable from outside the process.  It is also possible
  60. in a standalone environment to have a user defined version of exit that
  61. doesn't cause program termination but some other behaviour (and also being
  62. extern "C" void exit(int); ).
  63.  
  64. >And remember, never use gotos.
  65.  
  66. Use breaks, continues, mid-function returns and gotos if you want to.
  67.  
  68. Ramon Pantin
  69.