Re: sqrt C function
Dimitri Maziuk wrote:
> Sorry, Craig, WTF cares what "a conforming" compiler is "not prohibited"
> to do?
Because that was the question under discussion: whether the standard
allows a compiler to do that. Someone (I forget who now) thought not;
I disagreed.
> The question is "is my 'now even more standards-compliant than ever'
> compiler *guaranteed* to *always* compile that to identical object code?"
That's a separate question, also worthwhile, but quite distinct. For one
thing, yours is a practical question, whereas the original was
theoretical.
> AFAICT float f = 4.0; tells the compiler to assign floating-point value
> of 4.0 to f. float f = 4; tells it to take integer value of 4, make a
> float out of it, and assign the result to f.
Right, so the only question is whether the conversion from integer to
float will occur at compile time or at runtime. Obviously, for
performance, one would prefer compile time.
> Your compiler may do it
> right, and your code may never be compiled with another compiler.
> Unfortunately, "may" != "always will".
Of course. But this was a theoretical question about what is and is not
an allowable optimization, not a practical question of how code should
be written in real life. There are all sorts of things that I
would never write, but which I would be perfectly happy to discuss as
theoretical exercises. This is one such.
I suppose one could get even more pedantic by observing that the
original question regarded doubles, not floats, and that 4.0 is,
strictly speaking, a float literal, not a double literal. So there's a
still the possibility of a runtime conversion with "double f = 4.0". You
would have to explicitly mark the literal as a double to be sure that
even the dumbest compiler would do the right thing. (I forget how one
does that... 4.0L, perhaps?)
Another question, practically speaking, is whether _any_ modern compiler
would be so dumb as to let that conversion happen at runtime. If not,
then the "may" becomes a very strong "may", almost tantamount to "always
will". And perhaps that's good enough. YMMV.
> My point, which you seem to have missed, was "given the choice between
> explicitly specifying something and trusting the compiler to do the
> right thing, always choose the former".
I didn't miss it, and in general I agree, but it wasn't what we were
talking about.
Craig
Reply to: