GGggreg84·Mar 4, 2022
> And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution-...
The example on that blog post is not representative of how error codes are used.
On all programming languages, C included, but also Rust, functions return a completion value that's either success, or error (and when its error, it includes which error it is, and the error state, etc.).
int foo();
switch (foo())
case 0: break; // success
case 1: /* error case 1 */
case 2: /* error case 2 */
...
Instead, the blog post has the function return some value in registers that is not an error, and passes the function an ErrorState* as an argument, that the function first sets via memory, and then the handler reads, also via memory.
That this
Read the rest
is slow is not rocket science, which is why nobody does this.
I get why the author has to do it. If they were to do it right, error codes would perform significantly better than exceptions. Since returning the error or success is "free" (the function has to return anyways, and up to 2 registers are reserved by the ABI anyways).
Somebody mentions this in the comments, were as far as fixing it and sending a PR (https://github.com/jpakkane/excspeed/pull/1) but the author complains that this is not how GLib does error codes, so they don't care.
So yeah, if you do C error codes like GLib does, which is essentially a poor man's emulation of exceptions, then sure, exceptions are faster than doing error codes wrong.
Most people using C do it right, and so does Rust's Result (and all Rust programs).