[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Comparing KFileItems
From:       Michael Pyne <mpyne () kde ! org>
Date:       2012-10-19 0:11:23
Message-ID: 2142211.pA9X6tbnx6 () midna
[Download RAW message or body]


On Thursday, October 18, 2012 13:54:09 Frank Reininghaus wrote:
> There are ways to fix or work around this problem inside Dolphin, but
> I'm wondering if it makes sense to change the way KFileItems are
> compared. If two items do not have the same d pointers, one could
> check if their URLs are equal and consider them equal in that case.
> Or, if that is not considered suffient for equality, do what
> KFileItem::cmp(const KFileItem&) does.
> 
> I see the following advantages and disadvantages:
> 
> Pro:
> 
> a) The implicit sharing is an implementation detail of KFileItem. At
> least I would not have expected that operator==() depends on this and
> only compares the d pointers.
> b) It could possibly prevent other bugs in the future and save debugging
> time.
> 
> Con:
> 
> Changing the way KFileItems are compared could considerably slow down
> comparisons of items which are not equal.
> 
> Any opinions about this?

Well, your pros are both correct (and you didn't even list that the current 
behavior is inconsistent between KFileItem::cmp() and KFileItem::operator==() 
;). But also, you list high CPU usage as a possible con, even though it's what 
got you into troubleshooting this in the first place!

I would recommend comparing the d-ptrs as done now as an early optimization 
and then falling back to KFileItem::cmp() (or the inlined equivalent) if the 
d-ptrs are different.

Regards,
 - Michael Pyne
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]