On Tue, 2004-08-31 at 22:49, Davi de Castro Reis wrote: > Since there are too many options and too many tradeoffs/scenarios, my > suggestion would be to go with a polymorphic implementation using a > union. So you create your hash using g_hash_table_new (linked list), > g_hash_table_linear_probing_new(), g_hash_double_hashing_new(), > g_hash_array_new() and so on. Then you simply feed the returned pointers > to the common methods (ex: g_hash_lookup()) and let the first byte of > the union demultiplex the correct call. The general rule we've followed in GLib is that exposing minor data structure differences or implementation details to the user is wrong. We've consistently, for example, rejected requests to add GRBTree to go along with GTree. (Which is an AVL tree.) If you can't give a clear and convincing description of why you should use container A or container B in 10 seconds, then the difference between the containers isn't worth worrying about for virtually all application programmers. And it's not worth bloating GLib to have both. If a linear probing hash table is actually better for most applications, then we should just change GHashTable to use it. The way to demonstrate this is to look around at how GHashTable is used in applications, GLib, GTK+, write some benchmarks that resemble those use cases, and show comparisons of speed / memory usage. If a linear probing hash table is only better for a million entry hash table, then probably you should just include your own hash table in your application. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part