Use error codes instead of string constants when throwing

[albinahlback]

Quoting Fredrik in https://github.com/flintlib/flint/issues/1704#issue-2069243887, we have around 0.3 MB of strings in the library. I suppose most of this comes from throwing functions.

I think the solution to reducing this number is to create a large array of error values (enum only) joined with an array error strings in some source file. Then one should call the throwing function as follows:

throwing_function(__func__, ERROR_CODE[, var_1, ... var_n])

For example, the throwing function in flint_mul_sizes could become

throwing_function(__func__, FLINT_MUL_SIZES, x, y);

where x and y are the sizes that creates the overflow, which would be printed as

Overflow when multiplying sizes {print x} and {print y}

Hence, each error code should have a fixed number of variables of fixed types. This could then be wrapped with a macro to simply

THROWING_FUNCTION(ERROR_CODE[, var_1, ... var_n])

to avoid writing __func__ each time.

This solves two problems:

1. No duplicate error strings. In the case for flint_mul_sizes, it is inlined and therefore it will create a local string for this at each place it gets called at (at least every translation unit). Moreover, it will also have a symbol, and so it will have another string.
2. Smaller object files apart from the exceptions' object file. Perhaps results in faster loading of the library, hence faster code?

[fredrik-johansson]

I suppose most of this comes from throwing functions.

I really doubt that error message make up a significant fraction of the library size. Can we actually get a count?

[albinahlback]

I really doubt that error message make up a significant fraction of the library size. Can we actually get a count?

Not sure how to do that without turning the library upside down.

Suppose that the number from the program was correct. Where would the other strings come from? Printing functions have some strings, but not enough to make up more than, say, a couple kilobytes. Does any other functions contribute towards this number? Or perhaps the program interpreted other things as strings?

[fredrik-johansson]

IIRC this is for a debug build so I guess a fair number of strings are function names and file names.