C ++声明平台无关的32位浮点数

Question

Is there a way to declare 32-bit floating point value in C++ - ensuring that it will always be 32 bits regardless of platform/compiler?

I can do that for integers like that:

#include <stdint.h>

uint32_t var;  //32 bit unsigned integer
uint64_t var1; //64 bit unsigned integer

is there a way to do something like that for floats? As far as I know,

float var; //Usually is 32 bit, but NOT GUARANTEED to be 32 bit

is implementation specific, and is not necessarily 32 bit.. (Correct me if I am wrong).

I am using qt, so if there is any solution using it I would accept it - I couldn't find anything like quint16 for floats (qreal changes size depending on platform).

Answer 1

You're using Qt. which is specific to C++, so I'm not sure why the question is tagged C.

As far as I know, on all platforms where Qt is supported, type float is 32-bit IEEE.

If somebody decides to port Qt to, say, a Cray vector machine with 64-bit float , you're not going to have a 32-bit floating-point type anyway (unless you implement it yourself in software, but I don't see how that would be useful).

There is no <stdfloat.h> / <cstdfloat> corresponding to <stdint.h> / <cstdint> . C and C++ provide float , double , and long double , and imposes minimal requirements on them, but doesn't give you a way to ask for a floating-point type of any specific size.

Your best bet is probably to add something like this in main , or in some function that's guaranteed to be called during program startup:

assert(CHAR_BIT * sizeof (float) == 32);

and perhaps CHAR_BIT == 8 as well if your code implicitly depends on that.

It's unlikely that the assert will ever fire -- and if it does, you've got bigger problems.

You might want to reconsider whether you really need a 32-bit floating type. If your code were running on a system with 64-bit float , how would that fail to meet your requirements?

Answer 2

There isn't such a sized floating point type, but you can always statically assert that the size is 32 bits. Maybe even something as simple as a global char array:

#include <climits>

char static_assert_float32[1 - (2 * ((sizeof(float) * CHAR_BIT) != 32))];

This will fail to compile if float is not 32 bits by declaring an array of negative size.

Answer 3

Most common implementations of C and C++ will use 32 bit float types. If you really need to catch any platforms where that won't be the case you can use the following to throw an error early in the program:

#include <limits.h>
if (sizeof(float) * CHAR_BIT != 32)
    // error code here

Unfortunately I don't know of a way to detect it at compile time, my earlier answer was flawed.

Answer 4

On a platfrom that supports IEEE-754 float it's going to be 32 bit. On platforms that don't, different width will probably be the least of your problems. Bottom line - use float and don't worry.

Answer 5

The Boolean static member constant std::numeric_limits<float>::is_iec559 is true if and only if float conforms to the IEC 559/IEEE 754 floating-point standard. You'll need to #include the header <limits> .

Note that this alone doesn't tell you whether or not float is specifically 32-bit IEEE floating point, just that it is IEEE floating point -- some implementation without 32-bit floating point hardware might, for example, choose float be 64-bit IEEE floating point.

Answer 6

Knowing that the sizeof(float) is 32 bits may be sufficient, in general, but insufficient in all cases.

IEEE 758 defines the well known 32-bit binary32 which is commonly implemented. But IEEE 758 also defines a 32-bit decimal32 , which is primarily use for storage and not computation. There also exists other non-IEEE 758 32-bit floating point implementations, though certainly not as common.

Even if it is known that float is 32-bit IEEE 758-2008 binary32 , the degree which a given environment adheres to its strict definitions (Nan, subnormals, rounding modes) may vary. This I suspect is the greatest source of subtle variation of 32-float implementations.

Thus the goal of knowing precisely the floating point model used, likely to gain insure consistency across platforms, may be very challenging to detect at compile time.