Re: [boost] [Endian] Unaligned fields in packed structs

Subject: Re: [boost] [Endian] Unaligned fields in packed structs
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-06 21:08:33

>...
>
> Anyway, before I tried this I was already wondering about the choice of
> function signatures:
>
>  void endian::reorder(T&);  // in-place byteswap
>  void endian::reorder(T src, T& dest);  // out-of-place byteswap
>
> What is the rationale (or precedent) for these and not
>
>  T endian::reorder(T);
>
> ?

The endian/conversion.hpp interfaces are very immature compared to the
endian/integers.hpp interfaces, so it is well worth taking a hard look
at your questions.

The unconditional interfaces and conditional interfaces were designed
as a set, so they do things in a similar way.
If native_to_big, as an example, was supplied only as:

    T native_to_big(T x);

then the code for big-endian systems wouldn't just be a no-op. A copy,
no matter how fast, is a slower than a no-op. Of course a really smart
compiler might optimize the do-nothing copy away.

Also, some real applications deal with records of many fields, so you
get long strings of:

     reorder(rec.f1);
     reorder(rec.f2);
     ...etc.

It is a bit wordier to have to write:

    rec.f1 = reorder(rec.f1);
    rec.f2 = reorder(rec.f2);
    ...etc.

I'll run some timings tomorrow to see how actual release build timings differ.

--Beman