home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20005 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.7 KB  |  69 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
  3. From: jss@lucid.com (Jerry Schwarz)
  4. Subject: Re: setjmp/longjmp question
  5. Message-ID: <1993Jan27.045937.10463@lucid.com>
  6. Sender: usenet@lucid.com
  7. Reply-To: jss@lucid.com (Jerry Schwarz)
  8. Organization: Lucid, Inc.
  9. References: <1993Jan8.195613.14303@cadkey.com> <KANZE.93Jan25184636@slsvdnt.us-es.sel.de>
  10. Date: Wed, 27 Jan 93 04:59:37 GMT
  11. Lines: 56
  12.  
  13. In article <KANZE.93Jan25184636@slsvdnt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
  14.  
  15. |> 
  16. |> The C++ standards committee have said that they are adopting the C
  17. |> library more or less integrally, so I would suppose that this means
  18. |> setjmp/longjmp too.
  19.  
  20. The committee decided to include setjmp/longjmp, but with the
  21. proviso 
  22.  
  23.     "If any automatic objects would have been destroyed as a 
  24.     result of an exception passing control to the same function
  25.     as the longjmp, the results of the longjmp are undefined."
  26.  
  27. In effect, this means that longjmp is present and will work the
  28. way it does in C provided all your code stays in the C subset.
  29. In code using constructors and destructors (what some people
  30. might call "real C++") you shouldn't use it.  Note it isn't
  31. just that the destructors may or may not be called, but the
  32. exception handling mechanism itself might be corrupted by
  33. use of longjmp.
  34.  
  35. I believe there were three points of view expressed during
  36. the discussions leading up to this decision.
  37.  
  38. A) Not include them in the standard library. Vendors would be 
  39.    free to continue to support them in any way they chose.
  40.  
  41.    The objection to this was that it might severely
  42.    impact people trying to turn C code into C++. 
  43.  
  44. B) Include them and "fix them" to call the destructors (the
  45.    way exceptions would). 
  46.  
  47.    The objection to this is that a lot of C++ code already 
  48.    exists that uses longjmp/setjmp and doesn't expect the
  49.    destructors to be called.  This alternative might 
  50.    severely impact such code. And it would 
  51.    make it  difficult to write code that works both
  52.    with today's systems and future systems that implement
  53.    this rule.
  54.  
  55. C) Include them and say they don't call destructors. 
  56.    
  57.    The objection to this is that the standard shouldn't contain
  58.    a mechanism for subverting the usual guarantee that destructors
  59.    are called when stack variables are deallocated.
  60.  
  61. I believe this will work out reasonably well.  People can continue
  62. to use setjmp/longjmp.  As vendors phase in exception handling 
  63. they ought to continue to support existing use of setjmp/longjmp
  64. As systems without exceptions fade away programmers should discontinue
  65. using setjmp/lonjmp.  (Although I personally think the transition
  66. period will be measured in decades.) 
  67.  
  68.    -- Jerry Schwarz
  69.