| Re: [AD] a fix struct for dallegro |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Chris Robinson wrote:
I'm not sure we really need to worry about a fix class. I'd even recommend
taking it out of Allegro proper, but we can't for compatibility reasons.
AFAIK, the reason for having a fixed type was because floats were too slow at
the time, if even available at all. The fixed type was made to use integers
in an efficient manner to do the same job as floats. This is generally not
the case anymore, as FPUs are much faster these days, but I'll still be the
first to admit there are uses for fixed types. However, I'd still be hesitant
in making them freely mixable with other number types.
The Wikipedia page on fixed point seems to suggest that fixed point is
becoming more relevant instead of less.
http://en.wikipedia.org/wiki/Fixed-point_arithmetic
IMO the fixed type should not be made transparent as the fix class makes
it. 'fixed's designed use is fundamentally different than floats (speed over
correctness), and it's use should be explicit, even outside of the scope of
casting. The difference is easilly apparent in the functions that take/return
Allegro Degrees instead of radians.
Being able to use fixed types the same way as floats is just asking for
problems, especially when users can be expected to mix types (float here,
fixed here for this tight loop, double here because I need the accuracy..).
People need to know the full ins-and-outs of the fixed type, and being able
to just change a few type names and add a couple casts encourages people to
be careless, which leads to errors and obscure bugs.
I could simply remove the floating point overloads of the operators. So
the only interaction between fixed and floats would be this:
fix(2.5); // static opCall, wraps ftofix()
fix f = 2.5; // same function as above is called here
double d = f.toDouble(); // wrapper for fixtof()
f + 2.5; // error, no opAdd(double)
f + fix(2.5); // ok
f = 2.5; // error, no opAssign(double)
f = fix(2.5); // ok
etc.
Does this match your idea of explicit?