[Qt-interest] strange qFuzzyCompare implementation

[Stephan Rose]

On Mon, 2009-04-13 at 20:15 +0200, Konrad Rosenbaum wrote:
> On Monday 13 April 2009, Reinhardt Behm wrote:
> > Your "solution" is totally unportable because your assumptions about the
> > representation of float numbers will only be correct on a x86 evironment.
> 
> Wrong. It is designed to work with IEEE 754 floats, which are stored in the 
> same endianess as integers on this platform.
> 
> Works on x86, x64, and most big-endian systems. Probably most systems.

You can add PowerPC and ARM to that list. I've done a lot of work with
automotive tuning software , both PC software and the software running
on the hand held devices. In a worst-case scenario, the car's processor
is PowerPC, which sends its data raw as it comes from it's memory to the
hand held unit which is running ARM. On the more high end units data
processing and display is done right then and there on the unit, or
alternatively (or low-end units) it is sent to the PC.

So that's 3 architectures that the floats are passing through. Other
than obvious little/big endian issues between the platforms we've never
had to worry about whether or not floats are IEEE745.

> 
> > And even there some compiler implementation might store floats
> > differently.
> 
> Very unlikely.

Extremely unlikely, especially since he's restricting the statement to
x86 only. Imagine the disaster that would result in if every binary file
you'd have to first find out which representation the floats are saved
in.

Even on hardware that has no floating point hardware, I just don't see
it. Using something else would just introduce compatibility issues. At
best, I can maybe see it for some really specialized hardware that has
some really really good reason for choosing a different representation.

> 
> > Try running it on e.g. an ARM platform and it will not word 
> > at all.
> 
> I doubt that. (Until someone shows me program output from an actual ARM or 
> ARM emulator. Please include the sizeof output of the chosen types.)
> 
> > This is no solution for a multiplatform toolkit like Qt. 
> 
> Besides my doubts for your pessimism, it is still not a good solution for 
> cross-platform, since it needs platform dependent adjustments for endianess 
> and the used int types. On some platforms it might(!) not work at all. 

Whether or not it's a good solution for Qt I really can't say, I just
threw it out there to try and help the original poster. 

> 
> Not that Qt would not already contain quite a few platform dependent header 
> files (guess where stuff like qint32 comes from), but this might be too 
> much.

Even better example I think is QAtomicInt and QAtomicPointer which I've
been dealing a lot with the past few days working on my lock-free
containers. Doesn't get much more platform specific than those I'd say.

Stephan