3 ms·

> there is a guarantee here that noexcept functions don't throw. std::terminate has to be called. That has to be implemented Could you elaborate on how this ca

> there is a guarantee here that noexcept functions don't throw. std::terminate has to be called. That has to be implemented Could you elaborate on how this causes more overhead than without noexcept? The fact that something has to be done when throwing an exception is true in both cases, right?. Naively it'd seem like without noexcept, you raise the exception; and with noexcept, you call std::terminate instead. Presumably the compiler is already moving your exception throwing instructions off the happy hot path. Very very basic test with Clang: https://godbolt.org/z/6aqWWz4Pe https://godbolt.org/z/6aqWWz4Pe Looks like both variations have similar code structure, with 1 extra instruction for noexcept.

hifromwork 2y ago
Pick a different architecture - anything 32bit. Exception handling on 64bit windows works differently, where the overhead is in the PE headers instead of asm directly (and is in general lower). You don't have the setup and teardown in your example Throwing exception has the same overhead in both cases. In case of noexcept function, the function has to (or used to have, depending on architecture setup an exception handling frame and remove it when leaving. >Naively it'd seem like without noexcept, you raise the exception; and with noexcept, you call std::terminate instead Except you may call a normal function from a noexcept function, and this function may still raise an exception.
bregma 2y ago
If you're on one of the platforms with sane exception handling, it's a matter of emitting different assembly code for the landing pad so that when unwinding it calls std::terminate instead of running destructors for the local scope. Zero additional overhead. If you're on old 32-bit Microsoft Windows using MSVC 6 or something, well, you might have problems. One of the lesser ones being increased overhead for noexcept.
- account42 2y ago
  > Zero additional overhead. It's zero runtime overhead in the good case but still has an executable size overhead for functions that previously did not need to run any destructors.
  - bregma 2y ago
    Very true. Then again, if you don't need to tear down anything (ie. run destructors) during error handling you're either not doing any error handling or you're not doing any useful work.

hifromwork 2y ago

Pick a different architecture - anything 32bit. Exception handling on 64bit windows works differently, where the overhead is in the PE headers instead of asm directly (and is in general lower). You don't have the setup and teardown in your example Throwing exception has the same overhead in both cases. In case of noexcept function, the function has to (or used to have, depending on architecture setup an exception handling frame and remove it when leaving. >Naively it'd seem like without noexcept, you raise the exception; and with noexcept, you call std::terminate instead Except you may call a normal function from a noexcept function, and this function may still raise an exception.

bregma 2y ago

If you're on one of the platforms with sane exception handling, it's a matter of emitting different assembly code for the landing pad so that when unwinding it calls std::terminate instead of running destructors for the local scope. Zero additional overhead. If you're on old 32-bit Microsoft Windows using MSVC 6 or something, well, you might have problems. One of the lesser ones being increased overhead for noexcept.

account42 2y ago
> Zero additional overhead. It's zero runtime overhead in the good case but still has an executable size overhead for functions that previously did not need to run any destructors.
- bregma 2y ago
  Very true. Then again, if you don't need to tear down anything (ie. run destructors) during error handling you're either not doing any error handling or you're not doing any useful work.