2 ms·

It's similar to slapping noexcept on every function in a compilation unit. Unwinding will still happen as usual in compilation units where exceptions were enab

It's similar to slapping noexcept on every function in a compilation unit. Unwinding will still happen as usual in compilation units where exceptions were enabled. When a function in an -fno-exceptions compilation unit calls a function that might throw exceptions, the compiler inserts an exception handler that calls std::terminate. std::terminate won't call any destructors further up the chain, but if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter.

inetknght 3y ago
> if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. Note that closing system resources is often abortive. On the other hand, object destructors might wait for a flush.
wyldfire 3y ago
> if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. That "if" is doing some heavy lifting. C++ places a lot of stock in RAII, so failing to call destructors could cause lots of interesting failure modes. I don't think it's fair to dismiss this fundamental part of the language so easily.
- Calavar 3y ago
  If the user kills your program with Ctrl-C, you don't have any destructor guarantees. If your program is killed by the OS because the user logged off or powered down their machine, you don't have any destructor guarantees. If your program fails an assertion, you don't have any destructor guarantees. If your program segfaults, you don't have any destructor guarantees. This really isn't that exotic of a scenario. My personal opinion is that using RAII to do anything that you wouldn't trust the OS do for you in the event of an early termination is setting yourself up for disaster.
  - hamilyon2 3y ago
    Do you have a newsletter that I can sign up for?

inetknght 3y ago

> if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. Note that closing system resources is often abortive. On the other hand, object destructors might wait for a flush.

wyldfire 3y ago

> if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. That "if" is doing some heavy lifting. C++ places a lot of stock in RAII, so failing to call destructors could cause lots of interesting failure modes. I don't think it's fair to dismiss this fundamental part of the language so easily.

Calavar 3y ago
If the user kills your program with Ctrl-C, you don't have any destructor guarantees. If your program is killed by the OS because the user logged off or powered down their machine, you don't have any destructor guarantees. If your program fails an assertion, you don't have any destructor guarantees. If your program segfaults, you don't have any destructor guarantees. This really isn't that exotic of a scenario. My personal opinion is that using RAII to do anything that you wouldn't trust the OS do for you in the event of an early termination is setting yourself up for disaster.
- hamilyon2 3y ago
  Do you have a newsletter that I can sign up for?