Is there a C++ Standards compliant way to determining the structure of a 'float', 'double', and 'long double' at compile-time ( or run-time, as an alternative )?
If I assume std::numeric_limits< T >::is_iec559 == true
and std::numeric_limits< T >::radix == 2
, I suspect the is possible by the following rules:
- first X-bits are the significand.
- next Y-bits are the exponent.
- last 1-bit is the sign-bit.
with the following expressions vaguely like:
size_t num_significand_bits = std::numeric_limits< T >::digits;
size_t num_exponent_bits = log2( 2 * std::numeric_limits< T >::max_exponent );
size_t num_sign_bits = 1u;
except I know
std::numeric_limits< T >::digits
includes the "integer bit", whether or not the format actually explicitly represents it, so I don't know how to programmatically detect and adjust for this.- I'm guessing
std::numeric_limits< T >::max_exponent
is always2^(num_exponent_bits)/2
.
Background: I'm trying to overcome two issues portably:
- set/get which bits are in the significand.
- determine where the end of 'long double' is so I know not to read the implicit padding bits that'll have uninitialized memory.
In short, no. If
std::numeric_limits<T>::is_iec559
, then you know the format ofT
, more or less: you still have to determine the byte order. For anything else, all bets are off. (The other formats I know that are still being used aren't even base 2: IBM mainframes use base 16, for example.) The "standard" arrangement of an IEC floating point has the sign on the high order bit, then the exponent, and the mantissa on the low order bits; if you can successfully view it as anuint64_t
, for example (viamemcpy
,reinterpret_cast
orunion
—`memcpy is guaranteed to work, but is less efficient than the other two), then:for
double
:for `float:
With regards to
long double
, it's worse, because different compilers treat it differently, even on the same machine. Nominally, it's ten bytes, but for alignment reasons, it may in fact be 12 or 16. Or just a synonym fordouble
. If it's more than 10 bytes, I think you can count on it being packed into the first 10 bytes, so that&myLongDouble
gives the address of the 10 byte value. But generally speaking, I'd avoidlong double
.