[Issue 13420] double.nan unusable as AA key
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Fri Sep 19 11:54:02 PDT 2014
https://issues.dlang.org/show_bug.cgi?id=13420
Steven Schveighoffer <schveiguy at yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |schveiguy at yahoo.com
--- Comment #7 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Vladimir Panteleev from comment #6)
> Maybe the AA implementation should assert that keys added to it should be
> equal to themselves. That would make the problem easier to spot, at least
> (in my case it caused the output to be incorrect).
Yeah, possibly a good solution. But I think we should not pay the runtime
penalty for this rare situation (every access using every key type must be
checked). I actually think the current breakage of code is warranted, and this
is not going to cause a lot of problems (I would guess not many use nan keys).
Incidentally, typeid(float).compare is broken.
Observe:
float a, b=1; // a = nan
assert(!(a < b)); // test 1
assert(typeid(float).compare(&a, &b) < 0); // test 2
>From the definition of opCmp, this implies that from the result of test 1, test
2 should fail (compare(&a, &b) should be >= 0). In fact, I fully expected
compare(&a, &b) to be 0.
So your code only worked because:
a) the old AA implementation assumed compare(a, b) == 0 means equality (and as
has been discussed in the NG, this is not the case)
b) float.compare(x, y) can return -1 or 1 even when x or y is inf or nan!
I think we need another bug report for b)... (will add)
--
More information about the Digitalmars-d-bugs
mailing list