Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.