I'm trying to create a IEEE754 floating point number with the sign, exponent and mantissa, but I can't seem to get the ldexp() function working on my computer so I was wondering if there was a way to create that number by directly manipulating the bits' value.
1 Answers
One standard-ish idiom for messing with value representations is to work with your bits as part of an int
or char
array, and then memcpy()
that into your intended type.
Note that doing what you ask through writing one field of a union
and reading another, or through type-punning (casting and dereferencing pointers from one type to another, other than char*
) is technically undefined behavior under the C++ standard, and so should be avoided. Compilers are known to apply optimizations resulting from assumptions that that programs don't execute these behaviors, and lead to unexpected behavior when they do.
For the exact instance of pointer casting considered here, the Clang/LLVM developers have published in a blog post that this is undefined behavior that they may optimize in unexpected ways.

- 36,389
- 13
- 67
- 90
-
1When you copy bits to a floating point object you know that this works with your compiler. I.e. you know your compiler. Unless the compiler perversely doesn't support type punning I see no reason not to use it when the compiler is known. I would rather not use a compiler that forced me to *work around* its lack of support for a fundamental language feature. – Cheers and hth. - Alf Apr 17 '16 at 05:33
-
2Type punning and union access to a different type than what was last written are *undefined behavior* - the language literally invites compilers to do anything at all, and they do. See http://blog.regehr.org/archives/959 and the rest of Professor Regehr's blog for an in depth exploration of this topic. – Phil Miller Apr 17 '16 at 05:44
-
1@Cheersandhth.-Alf type punning (amongst certain types) and union aliasing are not fundamental features of Standard C++ – M.M Apr 17 '16 at 05:59
-
@M.M. Wrong. These features were crucial for the original design goals of C, as a portable language to reimplement Unix in. And they're still crucial in C++ for interfacing to ABIs, without which we wouldn't need C++ and could all just use C# or whatever. OK, exaggeration. But not much. – Cheers and hth. - Alf Apr 17 '16 at 08:14
-
-
@Novelocrat: Not sure why you're repeating yourself. A mystifying response. Don't you understand that a compiler can define a feature that's left UB in the standard -- and that that's what compilers do? Without this no standard library implementation could offer e.g. `offsetof`. And so on. – Cheers and hth. - Alf Apr 17 '16 at 08:17
-
@M.M. What "fact"? I never heard of this removal of C language features. Chapter and verse, please. – Cheers and hth. - Alf Apr 17 '16 at 08:17
-
1There is no chapter and verse for things that are not in the language. If you claim they are in the language you have to show C&V of where they are specified. – M.M Apr 17 '16 at 08:22
-
@M.M. You're claiming that e.g. `reinterpret_cast` or `union` are not in the standard. That's nonsense. Not even wrong. – Cheers and hth. - Alf Apr 17 '16 at 08:24
-
M.M. - you have that slightly wrong. The standard explicitly talks about union accesses. It says that programs can read from the same field of a union that was last assigned into. Accesses to any other union field are explicitly described as resulting in undefined behavior, and compilers observably generate programs with inconsistent results when the input code does that. – Phil Miller Apr 18 '16 at 14:38
-
1Cheers: `offsetof` may be defined in library code in some implementations, possibly even using constructs that would apparently result in UB if user code contained them (e.g. [arithmetic on a `NULL` pointer](http://stackoverflow.com/questions/15608366/is-performing-arithmetic-on-a-null-pointer-undefined-behavior)). The standard only requires that the compiler make that construct behave as expected - it doesn't require that user code that imitates it work as well. – Phil Miller Apr 18 '16 at 14:40
-
@Cheersandhth.-Alf No, he is not claiming that "`reinterpret_cast` or `union` are not in the standard". He is claiming that type punning through pointer casting and inactive union member access are undefined behavior, which they are in C++. In C99, union-based type punning is allowed, but not the violation of strict aliasing (e.g. dereferencing a pointer of the wrong type), and anyway C++ is not C… These features may have not been prohibited in old, non-standard dialects of C++, but today the standard precisely specifies what fall under "undefined behavior" – and these hacks do. – The Paramagnetic Croissant Apr 18 '16 at 14:49
-
@TheParamagneticCroissant: Re "He is claiming that...", you would have to provide a **quote** for that claim. It's simply untrue. His actual claim was nonsense, and the claim you falsely assign to him is also nonsense, like remarking that the Sun exists, it's just inane. So it doesn't matter much. Still, don't falsely attribute claims to others. Thanks. – Cheers and hth. - Alf Apr 18 '16 at 21:59
-
@Cheersandhth.-Alf here's the quote for you: "type punning (amongst certain types) and union aliasing are not fundamental features of Standard C++". Unfortunately, you didn't understand M.M point and tried to interpret this too literally (as in "does not exist") rather than what he meant (as in "it's UB"). I'm not sure if you are trolling, but every decent C++ programmer knows these abuses of the language have UB… If you don't believe me, maybe you will believe [some quotes from the standard](https://stackoverflow.com/questions/11373203/accessing-inactive-union-member-undefined-behavior)? – The Paramagnetic Croissant Apr 19 '16 at 04:30
-
Nobody has disputed that some type punning has UB. That's a PREMISE for this commentary and unlikely to be what M.M. meant, unless he was very tired or otherwise thinking very unclearly. As I already wrote, it's inane, and you're not helping him by proffering that creative interpretation. – Cheers and hth. - Alf Apr 19 '16 at 06:17