Detecting inadvertent use of integer division

Steven Schveighoffer schveiguy at yahoo.com
Tue Dec 15 06:57:02 PST 2009


On Tue, 15 Dec 2009 03:02:01 -0500, Don <nospam at nospam.com> wrote:

> Phil Deets wrote:
>> On Mon, 14 Dec 2009 04:57:26 -0500, Don <nospam at nospam.com> wrote:
>>
>>> In the very rare cases where the result of an integer division was  
>>> actually intended to be stored in a float, an explicit cast would be  
>>> required. So you'd write:
>>> double y = cast(int)(1/x);
>>  To me,
>>  double y = cast(double)(1/x);
>>  makes more sense. Why cast to int?
>
> That'd compile, too. But, it's pretty confusing to the reader, because  
> that code will only set y == -1.0, +1.0, +0.0, -0.0, or else create a  
> divide by zero error. So I'd recommend a cast to int.

I agree with Phil, in no situation that I can think of does:

T i, j;

T k = i/j;
U k = cast(T)i/j;

Make sense.  I'd expect to see cast(U) there.

You can think of it as i/j returns an undisclosed type that implicitly  
casts to T, but not U, even if T implicitly casts to U.

Wow, this is bizarre.

I like the idea, but the recommendation to cast to int makes no sense to  
me.  I'd also actually recommend this instead:

auto y = cast(double)(1/x);

On the idea as a whole, I think it's very sound.  Note that the only case  
where it gets ugly (i.e. requiring casts) is when both operands of  
division are symbols, since it's trivial to turn an integer literal into a  
floating point.

-Steve



More information about the Digitalmars-d mailing list