Re: hash table freeze is useless

> In Kazlib I have a different approach: there is a special delete function
> which does not resize the table. The documented intent is not for performance,
> but rather to allow the current item to be deleted during table traversal
> without destroying the validity of the iterator.

	In Glib, the hash table is opaque and the iterator is never known
to the user.  That is how Glib lets you use strings, structs, and other
such goodies as keys to your key/value pairs.

> Also, hash_insert doesn't perform any lookup: the constraint prohibiting
> duplicate keys must be validated by the application.

	Glib overwrites the value of the key/value pair if you supply a
key that already exists.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]