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
On 02/18/2014 05:53 PM, Stephan Bergmann wrote:
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
Hi Muthu,
tried to reach you on IRC yesterday:
Feb 13 11:03:42 sberg muthusuba, 8f8bc0dcf3bc253ae49159d52db049767f476ced is
broken: (a) the general O[U]String::hashCode does sampling-only by design; if that's
not considered good these days we should change the implementation rather than add
replying.
Thanks!
Muthu Subramanian
On 02/14/2014 02:59 PM, Stephan Bergmann wrote:
Ach, meant to send this to you instead of the mailing list...
Original Message
Subject: Re: [Libreoffice-commits] core.git: Move string hash function
into String class.
Date: Fri, 14 Feb 2014 10
On Fri, Feb 14, 2014 at 3:12 AM, Stephan Bergmann sberg...@redhat.com wrote:
On 02/13/2014 08:41 AM, Muthu Subramanian wrote:
+sal_uInt64 hashCode64() const SAL_THROW(()) ---
--- a/sal/rtl/strtmpl.cxx
+++ b/sal/rtl/strtmpl.cxx
+sal_uInt64 SAL_CALL IMPL_RTL_STRNAME(
On 14/02/14 11:46, Norbert Thiebaud wrote:
On Fri, Feb 14, 2014 at 3:12 AM, Stephan Bergmann sberg...@redhat.com wrote:
On 02/13/2014 08:41 AM, Muthu Subramanian wrote:
+sal_uInt64 hashCode64() const SAL_THROW(()) ---
--- a/sal/rtl/strtmpl.cxx
+++ b/sal/rtl/strtmpl.cxx
+sal_uInt64
On 02/14/2014 11:01 AM, Muthu Subramanian wrote:
a) Not sure what other things depend on hashCode - I assumed the
functions which call that
are ok with sampling based hash and needs it quick?
b) argh :( I added the rtl parts, I guess I missed the helper part -
will do.
c) Oops will change
On 02/14/2014 06:39 PM, Stephan Bergmann wrote:
O(1) sampling was apparently considered state of the art when the rtl
string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never
sampling more than 15 characters,
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
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
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
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'
12 matches
Mail list logo
