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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
