Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-26 18:35:08
With Beman's approach there is no extra overhead if the native type ==
If you use Beman's endian only for over-the-wire messages and then extract
the endian-aware types in/out to native types, then I think Beman's
efficiency is very good.
Beman's approach does provide several operators for endian-swappable types,
but I just don't use those operations, preferring to extract to native,
perform operations, and then store the result.
I have also extended Beman's general approach to floating point numbers with
very little effort.
What inefficiencies in Beman's approach should be corrected?
Also, network-byte-order isn't the only "correct" over-the-wire byte order.
Some of us still believe that little-endian is better. (Don't take the
Since the endian issue is larger than network-byte-ordering, I would suggest
removing any such references.
----- Original Message -----
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
Sent: Wednesday, May 26, 2010 12:07 PM
Subject: Re: [boost::endian] Request for comments/interest
> Tomas Puverle wrote:
>> I wrote an endian library on the flight back from boostcon
>> but it has taken a little time to clear the submission with
>> the firm.
> I recall our discussion of the inherent inefficiencies of Beman's
> approach -- that all operations on a boost::endian type potentially
> require swapping -- whereas the typical use case is to use native
> endianness until ready to read/write using wire format. It is only when
> ready to do I/O that there is a need to account for endianness.
>> I realize that Beman's endian swapper library is already in
>> the review queue but I hope my approach is different and
>> interesting enough to warrant consideration.
> Alternatives are good.
>> The highlights of the library are the following:
>> - Very simple interface: swap<machine_to_little/big>(),
> In my version of such functionality, I have byte_order::to_host() and
> byte_order::to_network() function templates. Those names are more in
> keeping with the C functions htons, ntohs, etc. I have versions that
> return a swapped copy of the input and those that take a non-const
> reference to a destination type, which means both types can be deduced and
> checked. Mine doesn't require the input and output type to be the same,
> but they must meet certain criteria checked via Boost.Concept Checking:
> they must be the same size, have the same signedness, and be of a
> supported size (currently up to 64 bits).
> namespace byte_order
> template <class T, class U>
> to_host(T &, U);
> template <class T, class U>
>> - Support for built-in and user-defined data types and
>> ranges thereof. E.g. you can swap ranges of structs
>> containing/deriving from other structs
> I haven't looked at the implementation you've selected, but there are
> several ways to do the swapping: casting among pointer types, straight
> casting, union-based punning, and memcpy(). The optimal choice for a
> particular data size and platform varies. The pointer-casting approach
> can lead to type punning problems for GCC without -fno-strict-aliasing.
> Whether to choose one approach for simplicity or use performance testing
> to find all of the special cases and select the approach -- including
> platform intrinsics -- to maximize performance, is the choice you must
>> - endian::iterator, which will iterate across a range
>> swapping values as necessary. It works with any swappable
> Nice idea!
>> The library is described/documented/tested in the file
>> main.cpp at the root of the zip archive.
> I'll try to have a look.
> 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 vi
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk