PDA

View Full Version : QVector3D, real



zaphod77
22nd March 2011, 19:09
hi coderz,

i'm new with Qt and like lot's of this.
what i do not know is, why Qt mix double/float for QVector3D.

...
private:
float xp, yp, zp;
...
public:
qreal length() const;

float for internal data presentation;
but real for access.

what is the reason for mixing float inside / real outside ?
thank you for answer,
greetings

SixDegrees
22nd March 2011, 20:16
qreal is an abstraction layer. At the end of the day, however, all such abstractions must resolve to actual data.

Santosh Reddy
22nd March 2011, 20:19
This is my version:
qreal is either float / double based on the type of hardware platform used to run the Qt Application, if the platform does not support float then a double is used.

ChrisW67
22nd March 2011, 22:19
If the platform does not support double (Symbian, Win CE, ARM, or no FPU) then qreal is defined as float.

QVector3D uses float internally, which means that some precision may be lost and some valid inputs may not be valid internal values on platform that do support double (most). This seems an odd choice. The reasoning may lie with the need to support QDataStream in a platform independent way, by using the lowest common denominator (float). If the internal representation was either float or double based on platform then the data stream would not be portable.

zaphod77
23rd March 2011, 11:14
thx for answers.
Portability seems the reason for real.
I've seen QVector3D from my point of view wich means - mass data - and i do not like to waste memory.
One day internal presentation will change to double and what will haben with my float arDots[10000000] ?

wysota
23rd March 2011, 21:38
It will overflow the stack :cool:

ChrisW67
23rd March 2011, 22:31
thx for answers.
Portability seems the reason for real.
There is no C++ type called "real" there is only float and double: qreal is a typedef for one or the other depending on platform. Both float and double use a standard binary representation (IEEE 754) and could be portable provided both ends of the transfer are expecting the same sized object, which they may not be. "qreal" does make cross-platform binary portability, but it does enhance cross-platform compilability.

Some platforms have no hardware support for floating point (i.e. no FPU) and have to handle floating point in software. If you couple that with a low powered CPU (Symbian mobile devices, ARM) then floating point is recipe for slow performance, and double doubly so. In a class with a heavy mathematical bent (matrix multiplications) performance is an issue and float makes sense. Having decided to use float on some platforms then you need to use float consistently if you expect binary compatibility of QDataStreams made from QVector3D objects.

That doesn't explain why the class interfaces are declared in terms of a variable "qreal" type rather than the underlying type. It is possible at the moment to construct a QVector3D with valid double inputs that overflow the internal float storage. This could be a Bad Thing(tm).



I've seen QVector3D from my point of view wich means - mass data - and i do not like to waste memory.

No idea what you mean here. If you don't like to waste memory then float is half the size of double (typically at least). Passing a few arguments in as double uses more RAM on the stack for the passed values: this is only temporary. If your environment is that tight that four extra bytes temporarily on the stack are a problem then perhaps you don't want a high-level OO language.


One day internal presentation will change to double and what will haben with my float arDots[10000000] ?
Nothing. The size of a float will not change, so your 10 million floats will be the same size.

If it were QVector3D data[10000000] then the storage required would change.

zaphod77
24th March 2011, 19:04
It will overflow the stack :cool:

float arDots[10000000] can be global and stack isn't touched - this is not the point

Added after 15 minutes:

I know that you can typedef everything :-)
Millions of real (double) values are double hungry.
We need fast acces on FE (Finite Elements) - > http://en.wikipedia.org/wiki/Finite_element_method AND a nice, crossplatform GUI.
So we need a lot :p
Thinking of use our own Vector-classes from previous project.
Target platforms are win,linux and mac.

thx for your posts and best code!