home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13329 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.5 KB
  1. Path: sparky!uunet!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Destructors and exit()
  5. Message-ID: <rmartin.715701864@thor>
  6. Date: 5 Sep 92 14:04:24 GMT
  7. References: <1992Sep3.220301.16983@murdoch.acc.Virginia.EDU> <rmartin.715615353@thor> <2384@devnull.mpd.tandem.com>
  8. Sender: news@Rational.COM
  9. Lines: 32
  10.  
  11. rgp@mpd.tandem.com (Ramon Pantin) writes:
  12.  
  13. |In article <rmartin.715615353@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  14. |>main()
  15. |>{
  16. |>  MyClass A;
  17. |>  static MyClass B;
  18. |>
  19. |>  exit();
  20. |>}
  21. |>
  22. |>
  23. |>The destructor for B should be invoked.  But the destructor for A
  24. |>probably will not.  I say probably, because a clever compiler might be
  25. |>able to figure out that, upon exit, the enclosing stack frames should
  26. |>be destroyed.
  27.  
  28. |IMHO, it would be incorrect for a compiler to "know" anything about
  29. |exit (exit is part of the C library, not part of the language, "exit"
  30. |is not a keyword).  A call to the exit function has never triggered
  31. |destructions of automatic objects and should never do.  The block where
  32. |the object was constructed is not being exited when the exit function
  33. |is called so it is incorrect to destroy the object. 
  34.  
  35. In general I agree with this. But I have seen compilers which have
  36. taken such liberties.  
  37.  
  38. --
  39. Robert Martin                        Training courses offered in:
  40. R. C. M. Consulting                       Object Oriented Analysis
  41. 2080 Cranbrook Rd.                        Object Oriented Design
  42. Green Oaks, Il 60048 (708) 918-1004       C++
  43.