Dimitri Maziuk wrote:
* Craig Dickson (crdic@yahoo.com) spake thusly: ...(2) Is there any essential difference between the following two declarations: double f = 4; double f = 4.0; such that a conforming C compiler is prohibited from compiling them^^^^^^^^^^ ^^^^^^^^^^to identical object code?Sorry, Craig, WTF cares what "a conforming" compiler is "not prohibited" to do? The question is "is my 'now even more standards-compliant than ever' compiler *guaranteed* to *always* compile that to identical object code?"
Is there anything in the language definition that specifies what the object code looks like as long as the code executes the programmer's intention. If we were talking about the compiler generating some intermediate non-machine code we would care.
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.
That of course was my original point.
Your compiler may do it right, and your code may never be compiled with another compiler. Unfortunately, "may" != "always will".
OTOH I have no problem with an optimizer that does something at compile time instead of run time as long as it doesn't break that correct standard meaning of an operator like '='. As I learned after my comment that started this thread gcc produces code which doesn't break the execute time result of the intention of the original code.
If the optimizer reduced a more complicated example in a similar fashion which broke the intention of the code I would be concerned. I will test that with gcc when I have the time.
My point, which you seem to have missed, was "given the choice between explicitly specifying something and trusting the compiler to do theright thing, always choose the former". That 4.0000000001234 crap was just an example off the top of my head -- sorry if it confused you.
My strategy is to trust the compiler until I find my code not doing what I intended it do. Paul Scott