Byte/Bit order in floating point representation

[Lauke]

Hi guys,

A trivial question (maybe...). I'm designing a library for math computation, and i was going to use the "bit field" to design my numerical data, i'm speaking of floating point computation.

Here is an example of wrapper:

typedef struct {
unsigned int mantissa : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
} representation;

typedef union {
float fl;
representation repr;
} my_float;

so that if i'm going to perform a statement like:
my_float my_fl;
my_fl.fl = 3.14;
unsigned int mant_fl = my_fl.repr.mantissa;

i straight obtain the mantissa without using any other function...
now the question is...

Is there some macro statement i can use if (basing on my machine or compiler i think) i can understand at once if it is better to both define

typedef struct {
unsigned int mantissa : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
} representation;

or

typedef struct {
unsigned int sign : 1;
unsigned int exponent : 8;
unsigned int mantissa : 23;
} representation;

I mean i suppose i can use something like

typedef struct {
#ifdef SOMETHING
unsigned int sign : 1;
unsigned int exponent : 8;
unsigned int mantissa : 23;
#else
unsigned int mantissa : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
#endif
} representation;


(i don't think for fixed point representation this should be a problem)

Cheers

[JLBorges]

The order of declaration of bit-fields do not specify the order in which the bit-fields are laid out in memory.

Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

[Note: Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. —end note ] - IS

[Lauke]

But i think that it could be some way to solve the problem, i mean... it's note a problem, but in order to make the code portable i think that it should be some way to derive the features of the system a priori.

[JLBorges]

On almost every implementation, std::numeric_limits<>::is_iec559 would be true for floating point types.
http://en.cppreference.com/w/cpp/types/numeric_limits/is_iec559

If this is true, the layout is as specified by IEC 559 / IEEE 754 https://en.wikipedia.org/wiki/IEEE_754-1985 and it would be possible to extract the sign, exponent and mantissa by bit shifting and masking of std::uint32_t / std::uint64_t values.

Note: IEC 559 / IEEE 754 does not specify endianness (when stored in memory); that is still implementation dependant.