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-06-03 01:02:13

Stewart wrote:
>
> You seem to be making a distinction between the communication/transfer 
> layer's endianness and that of the destination.  That is not the 
> distinction I make nor, I think, that Tomas is making.  For me, there are 
> two endiannesses that matter: the application's and the external, 
> communication/transfer layer's.  If the app must manipulate or inspect the 
> data, then its endianness is, of necessity, host order.  The means to 
> transfer the data elsewhere dictates whether and to which endianness the 
> application's order must be changed.  The apps consuming that data after 
> it leaves the first application are of no concern.  (Though one might 
> choose the external format to avoid any swapping where possible.)
>
> Once the data reaches another application, presumably the destination in 
> your wording, that application must deal with the communication layer's 
> endianness and decide whether to adjust it.  That swapping is wholly 
> independent of the swapping done by the first app.
>
> What Tomas noted is that the application's order should not change with 
> the external endianness unless the app does nothing with the data but 
> transfer it.  In that case, the app won't use the endian library at all. 
> OTOH, if the app does inspect of manipulate the data, then the endianness 
> will be swapped upon importation into the app and, possibly, again on the 
> exportation.  The swapping happens at the boundaries of the application. 
> Within the application, such data should always be in host order.

I agree with you that the over-the-wire or physical medium format is fixed 
and the apps must adjust.
I do agree that the host must convert the data into the native format to 
operate on it.
I do not agree that the entire message should be swapped-in-place unless 
performance is critical.

> Your code could be as efficient as using Tomas' swap(), but not 
> swap_in_place(), I think.  Measurements are good.

Good prediction!  The type-based code is more efficient than Tomas' swap() 
but less efficient than swap_in_place.
Both approaches are equally efficient for the same-endian case.

terry