Fwd: Re: [Libreoffice-commits] core.git: Move string hash function into String class.

Stephan Bergmann sbergman at redhat.com
Fri Feb 14 17:09:08 CET 2014


On 02/14/2014 04:11 PM, Muthu Subramanian wrote:
> On 02/14/2014 08:07 PM, Stephan Bergmann wrote:
>> On 02/14/2014 03:24 PM, Muthu Subramanian wrote:
>>> How else would we build a hash value without too much work?
>>
>> If you have a structure consisting of multiple parts, compute hash
>> values for the individual parts and fold them into a single hash value
>> via some suitable function, like f(x, y) = px + y for some prime p.
> Ah...that's what I meant by reusing the hash. Even in which case, there
> might be places where we might need large strings (may not make sense to
> break them smaller).

Sure, but how exactly rtl::O[U]String::hashCode should behave is 
somewhat orthogonal to the point that the current design of 
SdPage::getHash is needlessly resource-hungry.  And, as I wrote, "I 
wouldn't mind changing the rtl string classes' hashCode behavior."

> (E.g. SfxItemSet - its nicer to handle it as a group rather than
> individual Items)

Depends on your definition of "nice," I'd say. ;)

>>> I have added a hash for SfxItemSet as well recently. (Next step would
>>> be to reuse that hash in SdPage, of course).
>>
>> ...which I had just identified as dead code.  ;)  Please never
>> introduce unused code.  (And those stringify/hashCode functions
>> apparently also don't need to be virtual.)
> Which one, please? Maybe we are referring to different parts of the
> code? I am not aware of dead code per se :(

SfxItemSet::getHash and SfxItemSet::stringify

> hmm... I thought I marked them virtual - maybe not for SdPage - I didn't
> think SdPage required virtual?

That's my point---none of the getHash/stringify functions in SdPage, 
SdrObject, nor SfxItemSet should be virtual.

Stephan


More information about the LibreOffice mailing list