<div class="gmail_quote">On Sat, Jul 16, 2011 at 6:21 AM, Christian Manning <span dir="ltr"><<a href="mailto:cmanning999@gmail.com">cmanning999@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Jonathan M Davis wrote:<br>
<br>
> On Thursday 14 July 2011 06:27:47 Andrei Alexandrescu wrote:<br>
</div><div><div></div><div class="h5">>> On 7/14/11 5:51 AM, Regan Heath wrote:<br>
>> > That's my point. I need 8/16/32/64/128 bit versions and it really would<br>
>> > be better if there were general variants. My version are less than<br>
>> > optimal, but do use intrinsics where possible. Someone else can do a<br>
>> > far better job than I, and it really should be done once, by that<br>
>> > person. Surely we have the infrastructure for someone to add this to<br>
>> > phobos? If something this simple can't or won't be done, what hope do<br>
>> > we have!?<br>
>><br>
>> I think we should have these functions in std.bitmanip:<br>
>><br>
>> T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
>> T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
>> T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
>> T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
>><br>
>> That means all characters, all integers, and all floating point numbers.<br>
>> The implementations would opportunistically use intrinsics and other<br>
>> specialized means.<br>
>><br>
>> The documentation should specify the relationship to htonl and ntohl.<br>
>><br>
>> If there's a need for converting endianness of larger buffers, we might<br>
>> add:<br>
>><br>
>> ubyte[] toBigEndian(ubyte[] val);<br>
>> ubyte[] toLittleEndian(ubyte[] val);<br>
>> ubyte[] bigEndianToNative(ubyte[] val);<br>
>> ubyte[] littleEndianToNative(ubyte[] val);<br>
>><br>
>> They'd use std.algorithm.reverse internally as needed.<br>
>><br>
>> It's a sweet piece of work. Anyone have the time to prepare a pull<br>
>> request?<br>
><br>
</div></div><div class="im">> I decided to take a crack at it, and it seems to be going pretty well,<br>
> except that I can't seem to get the floating point values right. Somehow,<br>
> when I compare a floating point value with the same value except that it's<br>
> had its endianness swapped twice, they return true for is but false for<br>
> ==, which makes absolutely no sense to me. There's obviously either<br>
> something that I don't understand about floating point values (or the<br>
> relationship between is and ==) or a bug in dmd. It'd be one thing if I<br>
> couldn't get the values to reverse properly, but when they're equal<br>
> according to is but not ==, I have no idea how that could even be<br>
> possible.<br>
><br>
> - Jonathan M Davis<br>
<br>
</div>I've managed to get floating points working with unions. How are you doing<br>
it? Maybe you're triggering a bug somewhere<br></blockquote><div><br></div><div>After you swap it, do you return the result as a double or as a long? </div></div><br>