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