On Tue, Dec 16, 2008 at 18:29, Ravi <lists_ravi@lavabit.com> wrote:
On Tuesday 16 December 2008 16:17:10 David Abrahams wrote:
on Tue Dec 16 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
On Tue, Dec 16, 2008 at 3:03 PM, Pyry Jahkola <pyry.jahkola@gmail.com> wrote:
Gevorg Voskanyan wrote:
I suggest modifying CastFloatIter() function to use memcpy for accessing floats as integers, as shown below:
Hmm, I don't think it's any better than reinterpret casting.
Yes it is. It has the nice property of not leading to UB.
If so, that surprises me. Is it really guaranteed that all valid floating-point bit patterns are also valid integer bit patterns?
Not true; I am aware of at least one embedded platform where int is 24 bits whereas float on the same platform is 32 bits. As far as I can tell, the port of gcc that is used on this platform works fine for C; don't know about C++.
Given the static assert, it's still safe, since not compiling prevents UB. As for the bit patterns, I can't think of any bit patterns that cannot be created by legal <<ing and ++ing, so I'm not convinced that invalid integer bit patterns exist (at least in unsigned types -- I don't know what ones-complement signed ints do with ~0, for example). That said, how is it used in practise? Aliasing allows reading through an unsigned char*, the size of which is always a factor of the size of any other type, so would it be better to implement everything to always go through that? I know naïve radix sorts will often go CHAR_BIT bits at a time to take advantage of that, but I figure the better implementation may well need something more complex.