Am 21.07.2005 um 21:49 schrieb Jeremy Bettis:
I have a problem with the implementations of isEqual: and hash in
NSDate.
Let's say we have two dates:
NSDate *a, *b;
// This is actually a common case if you are doing floating point
math to generate dates and get small rounding errors.
a = [NSDate dateWithTimeIntervalSinceReferenceDate:100000.001];
b = [NSDate dateWithTimeIntervalSinceReferenceDate:99999.998];
printf("a = %d, b=%d, equal=%d\n", [a hash] , [b hash], [a
isEqual:b]);
// this code will print a = 100000, b = 99999, equal = 1
This breaks the NSDictionary rule that hash of two objects must
equal if they are -isEqual:.
While you are true with this rule and obviously true with -isEqual:
being broken, you shouldn't compare dates with -isEqual: but with -
isEqualToDate: and/or handle rounding errors more consciously:
if (fabs([a timeIntervalSinceReferenceDate] - [b
timeIntervalSinceReferenceDate]) <
someAmountOfSecondsYouConsiderNeglible) {
// they are equal
} else {
// they differ
}
- (BOOL) isEqual: (id)other
{
[...]
if ([other isKindOfClass: abstractClass]
&& (int)(otherTime(self)+0.5) == (int)(otherTime(other)+0.5) )
Any reason why you don't want to compare [self hash] to [other hash]?
my $0.02
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
