3 ms·

He means it causes resource leaks in any classes that implement RAII.

wolfgke 11y ago
SEH was there before C++ was fully standardized (first standardized version was C++98). In this sense one can argue that the definition of RAII is leaky since it "forgot" that SEH was already there and not the other way round. A proper solution would have been that functions where RAII is used must not call functions that can throw an SEH exception.
- pjc50 11y ago
  All kinds of functions can throw SEH exceptions, because they're machine check exceptions (divide by zero, reference invalid page/null pointer). I went and looked this up to refresh my memory: https://msdn.microsoft.com/en-us/library/swezty51.aspx https://msdn.microsoft.com/en-us/library/swezty51.aspx Microsoft recommend you don't mix the use of SEH exceptions with C++, or that you use the flag which turns SEH into C++ exceptions (and therefore calls destructors). In our case we didn't want to do that, because we're doing our own crash reporting and all we want is to log a backtrace while exiting the program, and do not want to call destructors which may themselves crash because the program is in an invalid state.
  - wolfgke 11y ago
    To me this all looks like stuff that is undefined behavior in C++, so a C++ program for which such a problem occurs is by definition invalid. In other words: You have a large problem in your code.
    - pjc50 11y ago
      Like I said: it's crash logging code, to be used for detecting problems in the code. Undefined behaviour is not invalid: if C++ compilers rejected all UB it would be considerably easier to ship (harder to write!) reliable programs.
      - wolfgke 11y ago
        No: The C++ standard requires from programmer that it will not trigger UB. This is a kind of contract between the programmer and the compiler.
        zvrba 11y ago
        The compiler vendor is free to extend the standard and define UB.
- kaushiks 11y ago
  C++ exception handling is implemented using SEH (so is CLR's IIRC, and Chakra's). SEH is implemented by the OS and is available to non-C++ code too (including C).

SEH was there before C++ was fully standardized (first standardized version was C++98). In this sense one can argue that the definition of RAII is leaky since it "forgot" that SEH was already there and not the other way round. A proper solution would have been that functions where RAII is used must not call functions that can throw an SEH exception.

pjc50 11y ago
All kinds of functions can throw SEH exceptions, because they're machine check exceptions (divide by zero, reference invalid page/null pointer). I went and looked this up to refresh my memory: https://msdn.microsoft.com/en-us/library/swezty51.aspx https://msdn.microsoft.com/en-us/library/swezty51.aspx Microsoft recommend you don't mix the use of SEH exceptions with C++, or that you use the flag which turns SEH into C++ exceptions (and therefore calls destructors). In our case we didn't want to do that, because we're doing our own crash reporting and all we want is to log a backtrace while exiting the program, and do not want to call destructors which may themselves crash because the program is in an invalid state.
- wolfgke 11y ago
  To me this all looks like stuff that is undefined behavior in C++, so a C++ program for which such a problem occurs is by definition invalid. In other words: You have a large problem in your code.
  - pjc50 11y ago
    Like I said: it's crash logging code, to be used for detecting problems in the code. Undefined behaviour is not invalid: if C++ compilers rejected all UB it would be considerably easier to ship (harder to write!) reliable programs.
    - wolfgke 11y ago
      No: The C++ standard requires from programmer that it will not trigger UB. This is a kind of contract between the programmer and the compiler.
      - zvrba 11y ago
        The compiler vendor is free to extend the standard and define UB.
kaushiks 11y ago
C++ exception handling is implemented using SEH (so is CLR's IIRC, and Chakra's). SEH is implemented by the OS and is available to non-C++ code too (including C).