Build error strings lazily #425
Assignees
Labels
Comments
eyalroz
added a commit
that referenced
this issue
Oct 9, 2022
* Added `throw_if_error_lazy()`, a macro alternative to the `throw_if_error()` function, which constructs the message string only when actually throwing an error * Using throw_if_error_lazy()` extensively in the API wrapper implementations
eyalroz
added a commit
that referenced
this issue
Oct 10, 2022
* Added `throw_if_error_lazy()`, a macro alternative to the `throw_if_error()` function, which constructs the message string only when actually throwing an error * Using throw_if_error_lazy()` extensively in the API wrapper implementations
eyalroz
added a commit
that referenced
this issue
Oct 10, 2022
* Added `throw_if_error_lazy()`, a macro alternative to the `throw_if_error()` function, which constructs the message string only when actually throwing an error * Using throw_if_error_lazy()` extensively in the API wrapper implementations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We may currently be wasting a lot of time building error strings, for all those
throw_if_error()calls.Instead, we should arrange it so that no string is built except when there's an error.
Ways this can happen:
throw_if_error()a macro (possibly a variadic macro taking many strings)throw_if_error()an (inlined) variadic template function which takes string-like objects. Their concatenation can happen conditionally within the function body (e.g. using a for_each_arg and such).The text was updated successfully, but these errors were encountered: