3 ms·

I dont kbow about go, but in C or C++, it's a common idiom to do something like: asset(condition && "static reason why we expected this condition to be true"

I dont kbow about go, but in C or C++, it's a common idiom to do something like: asset(condition && "static reason why we expected this condition to be true"); Unfortunately, this doesn't allow for a dynamic string, but does generally present a message about the assert. Also, if properly configured, a failed assert results in an abort and should generate a core/crash dump. Pretty useful to be able to load in a debugger for further inspection. But to the point about provide a good message: that's on the developer, and its going to be true no matter the language.

htfy96 7y ago
if (argc != 2) throw std::runtime_error("Expect 1 argument. Actual "s + std::to_string(argc - 1)); Don't get terrified by exception. If you don't catch any exception, then it is mostly abort() with dynamic string
- Asooka 7y 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 7y ago
    > It still incurs a nontrivial runtime cost, why do you care about the runtime cost of something that makes your program crash ?
    - fredsanford 7y ago
      Exceptions have a setup cost. You pay that setup cost every time an exception frame is created.
      - plorkyeran 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.
- int_19h 7y ago
  This will unwind the stack, executing destructors. Which is the last thing that you want to do in a scenario where conditions that were supposed to be invariants are broken. If your invariants don't hold, you don't really know what's going on - think of it as high-level undefined behavior. The faster you stop executing code within the security boundary (usually process), the better. This is exactly why assert() calls abort(), and why you should do so as well as soon as you've logged enough data to diagnose the issue.
barrkel 7y ago
Easier is to embed file and line number and possibly stringified assert expression via a macro. The string approach might help as a comment when reading the code, but suffers from all the problems comments do.
jdsully 7y ago
I usually just make my own AssertSz() macro that can take printf args. Works great for those pernicious asserts that need more data.

htfy96 7y ago

if (argc != 2) throw std::runtime_error("Expect 1 argument. Actual "s + std::to_string(argc - 1)); Don't get terrified by exception. If you don't catch any exception, then it is mostly abort() with dynamic string

Asooka 7y 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 7y ago
  > It still incurs a nontrivial runtime cost, why do you care about the runtime cost of something that makes your program crash ?
  - fredsanford 7y ago
    Exceptions have a setup cost. You pay that setup cost every time an exception frame is created.
    - plorkyeran 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.
int_19h 7y ago
This will unwind the stack, executing destructors. Which is the last thing that you want to do in a scenario where conditions that were supposed to be invariants are broken. If your invariants don't hold, you don't really know what's going on - think of it as high-level undefined behavior. The faster you stop executing code within the security boundary (usually process), the better. This is exactly why assert() calls abort(), and why you should do so as well as soon as you've logged enough data to diagnose the issue.

barrkel 7y ago

Easier is to embed file and line number and possibly stringified assert expression via a macro. The string approach might help as a comment when reading the code, but suffers from all the problems comments do.

jdsully 7y ago

I usually just make my own AssertSz() macro that can take printf args. Works great for those pernicious asserts that need more data.