3 ms·

It still incurs a nontrivial runtime cost, unless you've ifdef'd it away in release builds, but even so it is a heavy price to pay in debug or semi-debug^ build

by Asooka 8y ago

It still incurs a nontrivial runtime cost, unless you've ifdef'd it away in release builds, but even so it is a heavy price to pay in debug or semi-debug^ builds for things like container operator[] bounds checking. The best implementation of assert I've seen raises SIGTRAP on error, which neatly lets you attach a debugger and break when the error occurs, at which point you have the full stack trace and program state. ^ semi-debug in our case means minimal optimisations and debug asserts enabled.

jcelerier 8y ago
> It still incurs a nontrivial runtime cost, why do you care about the runtime cost of something that makes your program crash ?
- fredsanford 8y ago
  Exceptions have a setup cost. You pay that setup cost every time an exception frame is created.
  - plorkyeran 8y ago
    That is not true on most platforms in use today. The Itanium ABI uses "zero cost" exceptions which do not have any setup or runtime cost when an exception is not thrown (at the cost of making throwing exceptions much more expensive than other schemes). 64-bit Windows and arm64 use similar schemes.
    - fredsanford 8y ago
      I guess I have to use weasel words in every post now. Let's pretend my previous post started with "In most cases, "
      - Dylan16807 8y ago
        But that's the point, it's not most. GCC and Clang default to zero-cost DWARF. Add Windows and Arm64 and that's almost everything.
      - jcelerier 8y ago
        The only "relevant" platform where exceptions aren't zero cost nowadays is 32-bit windows - not even 64-bit one. so no, absolutely not "in most cases".
- jasode 8y ago
  >why do you care about the runtime cost of something that makes your program crash ? I think both parent commenters (htfy96 and Asooka) got on a tangent because htfy96 substituted a throw exception for an assert() in gp's (hermitdev) code -- as if they were equivalent. However, exceptions have fundamentally different semantics from asserts and are not substitutes for each other. (For anyone unfamiliar with the different purposes of exceptions vs asserts, please read the top 2 answers in this Stackoverflow question.[0]) Things like array bounds checking (used as a runtime safety check instead of an "impossibility" check) would not be tested with assert(). To answer your direct question, programmers who use assert() correctly for "testing their understanding of the world by testing an impossible condition" don't want to pay a runtime penalty for it. [0] https://stackoverflow.com/questions/1467568/debug-assert-vs-exception-throwing/1468385 https://stackoverflow.com/questions/1467568/debug-assert-vs-...
barrkel 8y ago
Bounds checking is one of those things that's easy for a compiler to hoist out of a loop and for branch prediction to guess right when not. It has very high value to cost ratio.

by Asooka 8y ago

jcelerier 8y ago

> It still incurs a nontrivial runtime cost, why do you care about the runtime cost of something that makes your program crash ?

fredsanford 8y ago
Exceptions have a setup cost. You pay that setup cost every time an exception frame is created.
- plorkyeran 8y ago
  That is not true on most platforms in use today. The Itanium ABI uses "zero cost" exceptions which do not have any setup or runtime cost when an exception is not thrown (at the cost of making throwing exceptions much more expensive than other schemes). 64-bit Windows and arm64 use similar schemes.
  - fredsanford 8y ago
    I guess I have to use weasel words in every post now. Let's pretend my previous post started with "In most cases, "
    - Dylan16807 8y ago
      But that's the point, it's not most. GCC and Clang default to zero-cost DWARF. Add Windows and Arm64 and that's almost everything.
    - jcelerier 8y ago
      The only "relevant" platform where exceptions aren't zero cost nowadays is 32-bit windows - not even 64-bit one. so no, absolutely not "in most cases".
jasode 8y ago
>why do you care about the runtime cost of something that makes your program crash ? I think both parent commenters (htfy96 and Asooka) got on a tangent because htfy96 substituted a throw exception for an assert() in gp's (hermitdev) code -- as if they were equivalent. However, exceptions have fundamentally different semantics from asserts and are not substitutes for each other. (For anyone unfamiliar with the different purposes of exceptions vs asserts, please read the top 2 answers in this Stackoverflow question.[0]) Things like array bounds checking (used as a runtime safety check instead of an "impossibility" check) would not be tested with assert(). To answer your direct question, programmers who use assert() correctly for "testing their understanding of the world by testing an impossible condition" don't want to pay a runtime penalty for it. [0] https://stackoverflow.com/questions/1467568/debug-assert-vs-exception-throwing/1468385 https://stackoverflow.com/questions/1467568/debug-assert-vs-...

barrkel 8y ago

Bounds checking is one of those things that's easy for a compiler to hoist out of a loop and for branch prediction to guess right when not. It has very high value to cost ratio.