On Thu, 2009-06-18 at 13:46 +0100, Daniel Silverstone wrote: > On Thu, 2009-06-18 at 11:34 +0800, Bo Yang wrote: > > Hi, > > Sometimes, we need to use the lwc_string as a key of hash_table, > > and I think the best key for a lwc_string is the hash value of it. So, > > I add a new function to expose the hash value of a lwc_string, please > > review it, any comments are welcomed, thanks! > > The hash value is *NOT* guaranteed unique.
Indeed. > The *pointer* of the lwc_string is both unique, and guaranteed to exist > only once for a given string stored in a given state, thus allowing > pointer-equality tests. Also true. > I'm strongly against exposing the internals of how libwapcaplet works in > this manner. Is this exposing the internals, though? If you want to put a lwc_string into a hash table then you need to calculate a hash from the data. I'm not convinced that using the pointer to the string will produce a particularly good distribution within such a table. Therefore, the client currently has to calculate a hash itself from the string data. AFAICS, all this patch does is avoid the need for the client to calculate a hash by having lwc expose a hash value for each string. Whether lwc uses said hash internally is irrelevant imo. Given that the most common usage of hashes in lwc clients will be sets or maps, they could just use a balanced tree instead of a hash. Thoughts? J.
