On Wed, 2003-12-31 at 17:49, bulia byak wrote:
Why "better"? What if one day, we need 64 bit precision - do a global search and replace again?
Well... that's a good point, actually. gint32 isn't necessarily the best solution either. Actually it's a bad one because it leaves the search and replace necessary, but makes it marginally harder. More on that later.
However, my understanding was that NRLong and NRShort were actually intended to be specific sizes -- that was the original purpose of the gen-nr-config business in the first place; to find (by compiling and running a test program) what types were 16 or 32 bits or whatever on the current platform.
Otherwise C's native long or short could have been used directly.
Of course, I don't recall that real size checks were ever implemented, so they just ended up being long/short anyway. Go figure. :P
Now, as far as the best solution... I think what we really need are single types that are used specifically for integer and floating-point measurements/coordinates.
Note that I said single types. Making NRShort and NRLong the same only completely fixes things while they're guaranteed to be the same precision (in which case, why have separate types?).
The zoom bugs and many others we've had to deal with have been the result of mixtures of precisions (or simply just not enough precision) used, in the name of micro-optimizing memory usage.
Also, that way, if we need more precision later, we can just bump it up in that one type rather than having to rework a bajillion things using different precisions.
Off the top of my head, we could maybe have NR::Coord (for floating-point) and NR::ICoord (for integer). Any other suggestions?
-mental