On Friday, 28 March 2014 at 11:15:36 UTC, bearophile wrote:
Walter Bright:
I've done this before.
The ecosystem changes (internet, wikis, IDEs, appear), and
programmers too change (many learn JavaScript as first
language, etc). So what's important is if a feature is good
today. Past experience is useful, but only up to a point.
it's a pain
What is the pain caused by those numbers?
Bye,
bearophile
I think he's speaking about mantain the table with the errors
messages and errors code and I did a program that used a similar
approach. It was written in C so maping this values is too
expansive and tedious.
Instead of
error("undefined variable %s", id->name);
you need to:
error(ERR_UNDEF_VAR, get_error_msg_string(ERR_UNDEF_VAR),
ERR_UNDEF_VAR, id->name);
the error string should contains also error message itself but
the formatting too. Formatting are used in functions which do
accept a variadic arguments if you do some update in the string
and forget to add respective argument or change the order of your
enum member and it mismatch to error_msgs_strings table index you
just will print garbage/wrong error message and or number/crash
program.
const char *error_msgs_strings[] = {
"error code: %d undefined variable %s",
"...",
};
Also, I was using linear error codes in this example and you're
not looking for this, isn't? I don't know much application which
does somethng like this. In this case, a simple
error_msgs_strings[ERR_UNDEF_VAR] will not work and you need to
create a hashtable. To print a single error code you need to do a
search now just like it does for every identifier in the program.
It isn't too bad since compile errors aren't too often necessary
to do like a search for a identifier in the string table. But it
depending how large is your table of error messages and if you
are using an approach that isn't exit in the first error message,
it will make the edit-and-compile cycle too slow.
