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
Re: [Libreoffice-commits] core.git: Move string hash function into String class. · Norbert Thiebaud
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.