Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data

Subject: Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-06-14 18:01:33

----- Original Message ----- 
From: "Dave Handley" <Dave.Handley_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, June 14, 2010 7:38 PM
Subject: Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data

> 
> Vicente Botet wrote:
>> Tom's swap_in_place force to interpret all the fields of the structure with the same endianness.
> 
> Do you have a use case for the situation where fields of a structure have different endianness?  It seems a lot of complexity to add if there isn't a strong use case.

Terry has presented an example on this list. Beman's documentation has another one. I don't think this unusual, as most of the standardized protocols use big endian, and all the internal message payloads between two little endian machines should use little endian.

Anyway, my implementation works well also when all the leaves have the same endianness. Just use the domain big or little, which maps any type to a tree with all the leaves big or little respectively. Resuming, applications needing only uniform endianness, don't need to specialize the domain map.

I think in addition that the indirection domain_map gives is a good thing as identifies exactly in a generic way any case the user can need, without lost of efficiency (at least with compilers that have a reasonable optimizer, as for example gcc4.4)

Best,
Vicente