Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-01 11:11:09

> Note that it seems rare indeed to have a utility that
> does nothing but endianness conversion rather than needing to do something to
the data during the conversion.

I think what you describe is pretty close to what I had in mind.

And while the utility which does nothing but endian conversion does seem a bit
far fetched (perhaps some sort of network bridge which translates between two
different network layers?), I think a far more likely scenario is a program that
examines and modifies a portion of the data while performing "regularization" on
the rest of it.

I certainly didn't want to preclude that use case.

> Assuming an API like Tomas suggested, the utility can do all conversions with
at most one swap.  That efficiency is only possible, however, if the utility
does nothing to the data during the conversion.

Agreed.  Still, there seems no good reason to preclude it.  There are many great
programs I can't even begin to dream about.

>    enum host_relative_byte_order { big_endian, little_endian };

I prefer to use types to enums for the tags.

>    template <host_relative_byte_order, class T>
>    T
>    from(T);
<snip code>

I just want to make sure - your only issue right now is with the function names,
is that correct?

Please don't take this the wrong way, as this is just a matter of taste, but I
find your interface worse than mine.  It seems that you've gone from the two
functions to seven or eight.

As for the type conversions, I don't see why you need the endian swapper to do
them.  Would you be perhaps able to share a use case for this?

>    template
>    <
>       host_relative_byte_order From
>       , host_relative_byte_order To
>       , class T
>    >
>    T
>    swap(T);

Finally, I have tried and rejected the approach which includes the "from" and
"to" endianness.  The main reason is that I've found that I, myself, and other
developer using the library, had trouble remembering which parameter was "from"
and which was the "to", leading to bugs.  Hence the "machine_to_big" tag, which
is completely unambiguous.

Thanks,

Tom