Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at