Re: [AD] a fix struct for dallegro

[torhus@xxxxxxxxxx]

Peter Wang wrote:
> On 2007-04-15, torhus@xxxxxxxxxx <torhus@xxxxxxxxxx> wrote:
> > Since fixed is just an alias for int, there's still the danger of mixing 
> > fixed and int values.  So this solution isn't perfect.  I tried making 
> > fixed a D typedef, which would make it a completely distinct type from 
> > int.  But that requires a lot of casting when using it.
>
> In what cases?  I would think that most uses of fixed would require
> itofix, ftofix, fixtoi or fixtof calls anyway.


I was thinking about things like the implemention of itofix, etc.  Of 
course, it would only require adapting these functions.  They are 
implemented in D to allow them to be inlined.  This example illustrates 
the problem, keep in mind that typedefs in D are 'strong', as opposed to 
aliases that behave like C typedefs:

---
typedef int fixed;

void main()
{
   int i = 5;

   fixed f1 = 5 << 16;  // the compiler accept this, since no int vars 
are involved
   fixed f2 = i << 16;  // doesn't compile, no implicit conversion to 
int here
   fixed f3 = cast(fixed)(i << 16);  // explicit cast to fixed works
}
--

The type of the expression 'i << 16' above is int.  There is no such 
thing as user-defined implicit conversions in D, so one way or the 
other, it will have to be explicit.  So the fixed type wouldn't behave 
like in C-allegro anymore.  It would be more cumbersome to use.  But the 
fix struct would be safer because ints and fixed values couldn't be 
interchanged anymore.  You could have overloads that take a value of 
type fixed, in addition to those take than an int.


> >    fix sqrt()          { fix t;  t.value = fixsqrt(value);    return t; }
> >    fix cos()           { fix t;  t.value = fixcos(value);     return t; }
> >    fix sin()           { fix t;  t.value = fixsin(value);     return t; }
> >    fix tan()           { fix t;  t.value = fixtan(value);     return t; }
> >    fix acos()          { fix t;  t.value = fixacos(value);    return t; }
> >    fix asin()          { fix t;  t.value = fixasin(value);    return t; }
> >    fix atan()          { fix t;  t.value = fixatan(value);    return t; }
> >    fix atan2(fix x)    { fix t;  t.value = fixatan2(value, x.value);  return t; }
>
> Are these necessary?

Would you prefer to have only the free functions?  I added both because 
I wasn't sure which one would make the most sense.  Or should I remove 
them altogether?