Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
- Subject: Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
- From: Jens Alfke <email@hidden>
- Date: Fri, 03 Jan 2014 13:55:43 -0800
On Jan 3, 2014, at 1:29 PM, Asiga Nael < email@hidden> wrote: Yes, I think this sentence fully explains my surprise at how clang implements the -Wfloat-equal warning. Given that the issue of comparisons has nothing to do with the issue of representation, it looks absurd that clang decides whether to warn or not basing the decision just on representation and not on the nature of the comparison I think it’s a heuristic based on common usage. Since CoreGraphics, AppKit and UIKit all use floating-point graphics coordinates, application code ends up using floats a lot, and it’s not uncommon to make equality tests. In practice, app code almost always uses integer coordinates, or maybe an offset of 0.5 (for example to center a line nicely between pixel boundaries). I can imagine that the GCC-style warning would generate a lot of non-helpful noise in such app code. Suppressing the warning when comparing against integral constants, or those with exact binary representations, is a reasonable way to make a lot of common code work while still catching problematic cases like comparing against 0.1.
In other words, I suspect it was simply a design tradeoff that was resolved in a way you don’t find optimal. Throwing around a loaded word like “absurd” isn’t useful here; it just inflames tempers. The people who work on Clang are smart and experienced; please give them credit for that, whether or not you agree with everything they do.
—Jens
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden