Re: [boost] Proposed templated integer_sort

Subject: Re: [boost] Proposed templated integer_sort
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-16 18:42:23

On Tue, Dec 16, 2008 at 18:29, Ravi <lists_ravi_at_[hidden]> 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_at_[hidden]>
> 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.