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 the
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
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' hashC
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 indiv
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 valu
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 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, wi
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 t
On 14/02/14 11:46, Norbert Thiebaud wrote:
> On Fri, Feb 14, 2014 at 3:12 AM, Stephan Bergmann 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 S
On Fri, Feb 14, 2014 at 3:12 AM, Stephan Bergmann 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( hashCode64_WithLength )( co
while 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 20
Hi Muthu,
tried to reach you on IRC yesterday:
Feb 13 11:03:42 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
anoth
12 matches
Mail list logo
