Ar an cúigiú lá déag de mí Bealtaine, scríobh Jeff Sparkes:
I have a few sets of data I'd like to look up by name and get an
integer
back. I've been using alists because they're convenient and easy to look
at for debugging.
I've just created a list of gtk-cursor-names with 77 values. Should I
think about using a hash table? The values aren't looked up very often.
And luckily a default hash table does what I want; calling
make-hash-table with keywords from C appears scary.
The is really more of a style question than an efficiency question.
The X11 keysym code, which needs to do something similar, puts a property on
the associated symbol, like so:
(symbol-plist 'EuroSign)
=> (character-of-keysym ?€)
So for FROB_CURSOR, you could do something like:
DECLARE_EISTRING (scratch);
#define FROB_CURSOR(X) do { \
eireset (scratch); \
eicpy_ascii (scratch, #X + 4); \
eilwr (scratch); \
Fput (intern_massaging_name (eidata (scratch), Qgtk_cursor_type, \
make_int (0 + X))); \
} while (0)
FROB_CURSOR (GTK_ARROW);
[...]
and cursor_name_to_index becomes:
{
Lisp_Object res = Fget (intern (name), Qgtk_cursor_type, Qnil);
if (NILP (res) || !INTP (res))
{
invalid_state ("Gtk cursor names not registered", build_ascstring (name));
}
return (GdkCursorType) XINT (res);
}
That’s very cheap, and there’s an argument for doing it here for consistency
within XEmacs, but there’s also the counterargument that symbol plist
entries can’t have docstrings. You’d also have to declare the symbol in the
appropriate places; see how Qglyph_animated_timeout_handler is declared in
glyphs.c, as a random example.
Note that make_lisp_hash_table () is probably general enough for most C
callers, there’s no need to construct an argument vector for the keywords.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta