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

[Stephan Bergmann]

On 02/15/2014 04:51 AM, Muthu Subramanian wrote:
> On 02/14/2014 09:39 PM, Stephan Bergmann wrote:
>> 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."
>>
> Then I guess I didn't understand your view point completely :(
> I do agree that SdPage::getHash is resource hungry - currently.
> It would hopefully reduce its resource hungriness as we progress. Then
> again, it also depends on which resource ;)

I was alluding to dynamic memory allocation with "resource hungry."

>> SfxItemSet::getHash and SfxItemSet::stringify
> Na...these are used

Oops, my mistake.

>> That's my point---none of the getHash/stringify functions in SdPage,
>> SdrObject, nor SfxItemSet should be virtual.
> If its allowed to be inherited, its good to be virtual? Especially if we
> are looking at hash folding?

While a well-designed interface between a base class and its derivations 
(of which virtual functions are a part) is desirable, a virtual function 
carries a relatively high maintenance cost.  So please never declare 
functions as virtual until they actually need to be.

> I'll do what best I understood from this conversation (I hope I
> understood right!) and leave the rest to you? Hope that's fine, please?

Just pushed 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=042725a5dadc9f2c6368ca451b6d20046129b8af> 
"Stick to a single O[U]String hash function" based on what we discussed 
here.  Hope it still matches the requirements of SfxItemSet::getHash and 
SdPage::getHash (where I must confess that I don't understand what those 
requirements are) as well as the requirements of the 
svl::SharedStringPool clients (see the commit message for details).

Stephan