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

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 == 
endian 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 
bait). ;o)
Since the endian issue is larger than network-byte-ordering, I would suggest 
removing any such references.

terry

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_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>(),
>> swap_in_place<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>
>   void
>   to_host(T &, U);
>
>   template <class T, class U>
>   T
>   to_host(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 
> make.
>
>>       - endian::iterator, which will iterate across a range
>> swapping values as necessary.  It works with any swappable
>> type.
>
> 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
> ruses.
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>