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

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-01 08:14:41

Tomas Puverle wrote:
> Kim wrote:
> > Rob Stewart wrote:
>
> > > IOW, the spelling changes from "{from,to}_{big,little}_endian"
> > > to "{from,to}<{big,little}_endian>."
> >
> > Yes, something like that was what I had in mind.
>
> You certainly have the functionality to go from/to the host
> endianess to/from any other but how do you write code which
> needs to go from a specific endianess to another specific
> endianess?  It seem that would be much easier in my
> interface than with the one above.

I've never had the need to convert data from one specific endianness to another, though I can imagine some sort of conversion or translation utility doing so.  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.

There are several scenarios for converting X-to-Y endianness:

# | Source | Destination | Host
--+--------+-------------+-----
1 |   B    |   B         |   B
2 |   B    |   B         |   L
3 |   B    |   L         |   B
4 |   B    |   L         |   L
5 |   L    |   B         |   B
6 |   L    |   B         |   L
7 |   L    |   L         |   B
8 |   L    |   L         |   L

Assuming the API shown above, then cases 1 and 8 require no swapping at all, cases 3, 4, 5, and 6 require one swap, while cases 2 and 7 require two swaps, assuming that the utility swaps on read and again on write.  Such work cannot be avoided if the utility does anything to the data during the conversion.

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.

Now, one must consider the likelihood of needing to do such conversions.  I noted that I've never had the need to do so and would, generalizing from the specific, suppose such a need is rare.  Consequently, I'd conclude that while my API is less efficient in two of the cases, its simplicity makes it better for most, and certainly the most common, cases.  Does your experience differ?

Supposing that need important, supporting my suggested interface doesn't preclude a more generalized X-to-Y swapping which ignores the host order altogether.  Thus:

   enum host_relative_byte_order { big_endian, little_endian };

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

   template <host_relative_byte_order, class T, class U>
   void
   from(T &, U);

   template <host_relative_byte_order, class T>
   T
   to(T);

   template <host_relative_byte_order, class T, class U>
   void
   to(T &, U);

   enum byte_order { big_to_little_endian, little_to_big_endian };

   template <byte_order, class T>
   T
   swap(T);

   template <byte_order, class T, class U>
   void
   swap(T &, U);

Another approach for the latter:

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

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

(In that case, I'd rename host_relative_byte_order to just byte_order.)

That leaves the choice to the library user.  I presume from<>() and to<>() would be used more often.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.