<div class="gmail_quote">On 20 October 2011 15:13, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 20.10.2011 13:12, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 20 October 2011 11:02, Don <<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a><br></div><div class="im">
<mailto:<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>>> wrote:<br>
<br>
On 20.10.2011 09:47, Manu wrote:<br>
<br>
Many architectures do not support real, and therefore it should<br>
never be<br>
used implicitly by the language.<br>
<br>
Precision problems aside, I would personally insist that implicit<br>
conversation from any sized int always be to float, not double, for<br>
performance reasons (the whole point of a compiled language trying<br>
to supersede C/C++).<br>
<br>
<br>
On almost all platforms, float and double are the same speed.<br>
<br>
<br></div><div class="im">
This isn't true. Consider ARM, hard to say this isn't a vitally<br>
important architecture these days, and there are plenty of embedded<br>
architectures that don't support doubles at all, I would say it's a<br>
really bad idea to invent a systems programming language that excludes<br>
many architectures by its design... Atmel AVR is another important<br>
architecture.<br>
</div></blockquote>
<br>
It doesn't exclude anything. What we're talking about as desirable behaviour, is exactly what C does. If you care about performance on ARM, you'll type sqrt(2.0f).<br>
<br>
Personally, I'd rather completely eliminate implicit conversions between integers and floating point types. But that's just me.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I maintain that implicit conversion of integers of any length should<br>
always target the same precision float, and that should be a compiler<br>
flag to specify the desired precision throughout the app (possibly<br>
defaulting to double).<br>
</blockquote>
<br></div>
I can't believe that you'd ever write an app without that being an upfront decision. Casually flipping it with a compiler flag??<br>
Remember that it affects very few things (as discussed below).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you choose 'float' you may lose some precision obviously, but you<br>
expected that when you chose the options, and did the cast...<br>
</blockquote>
<br></div>
Explicit casts are not affected in any way.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Note that what we're discussing here is parameter passing of single<br>
values; if it's part of an aggregate (array or struct), the issue<br>
doesn't arise.<br>
<br>
<br></div><div class="im">
Are we? I thought we were discussing implicit conversion of ints to<br>
floats? This may be parameter passing, but also assignment I expect?<br>
</div></blockquote>
<br>
There's no problem with assignment, it's never ambiguous.<br>
<br>
There seems to be some confusion about what the issue is.<br>
To reiterate:<br>
<br>
void foo(float x) {}<br>
void foo(double x) {}<br>
<br>
void bar(float x) {}<br>
<br>
void baz(double x) {}<br>
<br>
void main()<br>
{<br>
bar(2); // OK -- 2 becomes 2.0f<br>
baz(2); // OK -- 2 becomes 2.0<br>
foo(2); // fails -- ambiguous.<br>
}<br>
<br>
My proposal was effectively: if it's ambiguous, choose double. That's all.<br>
</blockquote></div><div><br></div><div>Yeah sorry, I think you're right, the discussion got slightly lost in the noise here...</div><div><div><div><br></div><div>Just to clarify, where you advocate eliminating implicit casting, do you now refer to ALL implicit casting? Or just implicit casting to an ambiguous target?</div>
<div><br></div><div>Let me reposition myself to suit what it would seem is actually being discussed... :)</div><div><br></div><div>void sqrt(float x);</div><div><div>void sqrt(double x);</div></div><div><div>void sqrt(real x);</div>
</div><div><br></div><div>{</div><div> sqrt(2);</div><div>}</div><div><br></div><div>Surely this produces some error: "Ambiguous call to overloaded function", and then there is no implicit cast rule to talk about... end of discussion?</div>
<div><br></div><div>But you speak of "eliminating implicit casting" as if this may also refer to:</div><div><br></div><div>void NotOverloaded(float x);</div><div><br></div><div>{</div><div> NotOverloaded(2); // not ambiguous... so what's the problem?</div>
<div>}</div><div><br></div><div>or:</div><div><br></div><div>float x = 10;</div><div><br></div><div>Which I can imagine why most would feel this is undesirable...</div><div><br></div><div>I'm not clear now where you intend to draw the lines.</div>
</div></div><div>If you're advocating banning ALL implicit casting between float/int outright, I actually feel really good about that idea. I can just imagine the number of hours saved while optimising where junior/ignorant programmers cast back and fourth with no real regard to or awareness of what they're doing.</div>
<div><br></div><div>Or are we only drawing the distinction for literals?</div><div>I don't mind a compile error if I incorrectly state the literal a function expects. That sort of thing becomes second nature in no time.</div>