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

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-26 17:55:49

Hi Tom, how are you.
----- Original Message ----- 
From: "Tomas Puverle" <tomas.puverle_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 26, 2010 6:37 PM
Subject: [boost] [boost::endian] Request for comments/interest

> 
> 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 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.
> It's located here in the vault (Utilities/endian-puverle.zip):
> 
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=endian-puverle.zip&directory=Utilities&
> 
> The highlights of the library are the following:
> - Very simple interface: swap<machine_to_little/big>(),
> swap_in_place<machine_to_little/big>()
> - 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
> - endian::iterator, which will iterate across a range swapping values as
> necessary.  It works with any swappable type.
> 
> The library is described/documented/tested in the file main.cpp at the root of
> the zip archive.
> 
> Unfinished items:
> - Right now, the library only includes the "vanilla" swapper, meaning it
> doesn't take advantage of special instructions on architectures which natively
> support endian conversion.  I didn't include this in order to prevent cluttering
> the code with #ifdefs.  This functionality would, however, be part of the final
> library.
> - Ideally, the metafunction is_mutable_range<> should be moved out of
> endian::detail and become part of Boost.Range of Boost.TypeTraits.
> 
> I have donned by bulletproof vest and I'm ready for any feedback you may have. :)
> 

One of the advantages of the Beman's Endian library is that the endianes of the stored data is on the type. I think that this is a must, as very often the hidden endian bugs are are due to this fact.

I proposed to Beman to split the functionality of endian into two levels. The first level take care just of endian format and how to convert from one endian to the ether. The second defines integer endian types. The reason to split is that the cost of executing arithmetic operations that make two conversions each time is to high for a lot of applications, so it will be better to disallows these operations. Of course the user can not use them with the current design, but an error is always possible.

int a=0xABCD;
int b=endian::swap<machine_to_big>(a);

is done with Boost.Endian as follows

native32_t a=0xABCDEF;
big32_t b=a;

or 

int a=0xABCDEF;
big32_t b=a;

* I like your endian::swap idea to apply swap to structures. I have not see yet what BOOST_ENDIAN_UDT(Base, (i)(d)) does, but maybe something like that would be done

struct Base
{
    int i;
    short s;
};

struct BaseBig
{
    big32_t i;
    big16_t s;
};

We can see the structures as fusion sequences using the STRUCT_ADAPTOR. It should be not too complicated to 
define a conversion function that uses the fusion sequence views of both structures and that manage with endianes

Base b = {1234, 123};
BaseBig bb = convert<BaseBig>(b);

* My experience with swap in place is that it is very dangerous as you can swap in order to send a message and forget let the variable with the wrong format and make arithmetic operations on.

int a=0xABCD;
endian::swap_in_place<machine_to_big>(b);
... later on

which is the format of 'a'? Usualy the developer will think that it is native, but ...

* Maybe your design could perform better and allows in_place changes (which is risky), but if I had to start a project I will use the Beman's library, if the performances were supportable, which I think it is if we don't use arithmetic on endian types.

Resuming, there will be always people that prefere one or the other design.

Just 2 cts from one that had had a lot of endian issues.

Best,
Vicente