Boost logo

Boost :

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Rob Riggs (rob_at_[hidden])
Date: 2010-05-28 23:29:48

On 05/28/2010 09:30 AM, Tomas Puverle wrote:
>>> 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.
>> +1 on the naming. No matter what the interface morphs into, "network"
>> should be a valid synonym for "big_endian" for the reason stated.
> Hi Rob,
> I am not sure what your comment refers to exactly.
> Earlier in the thread we have already established that for many users, the
> "network" order may mean different things, and hence the reason why my library
> doesn't prescribe one in the first place.
Hi Tomas,

The term "network byte order" means the same to everyone who has had to
learn what endianness is. Why would one want ignore that the term
"network byte order" has real meaning in an endianness library? That
there are legitimate use cases for sending little-endian data over the
network is, to me, irrelevant.
> Are you saying that you would like it to do so? Or are you saying you would
> like to have another typedef, "machine_to_network"?
Acknowledging "network byte order" in the interface does not prescribe
anything. I am suggesting is that it should be a consistent synonym for
"big endian". Virtually all IETF binary protocols specify /network byte
order/ and everyone who reads the RFCs knows what that means. One need
only google 'rfc "network byte order"' to get a feel for its
pervasiveness. Ignoring it completely seems silly.
> I *could* add that with no problems, of course, BUT like I said, that typedef
> may mean different things to different people. I would almost prefer for this
> to be an application specific define
But it's not application-specific. It's a de facto world-wide standard.



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