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

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2010-05-26 22:11:32

Hi Terry,

> With Beman's approach there is no extra overhead if the native type == 
> endian type.

As is the case with my library, as you'd expect.

> If you use Beman's endian only for over-the-wire messages and then extract 
> the endian-aware types in/out to native types, then I think Beman's 
> efficiency is very good.
> Beman's approach does provide several operators for endian-swappable types, 
> but I just don't use those operations, preferring to extract to native, 
> perform operations, and then store the result.
> I have also extended Beman's general approach to floating point numbers with 
> very little effort.
> 
> What inefficiencies in Beman's approach should be corrected?

Note that I didn't criticize Beman's approach in my original email - I would 
just prefer to say that my approach is different.  

Here some of the differences in our philosophies:

1) Intrusive vs non-intrusive:  Endian swapping can be added/retrofited to any 
type using my library, even if you can't modify the original source code.  If 
I am not mistaken, Beman's library requires the data types which need to be 
swapped to be written using his endian types as members.

2) In your usage scenario, you actually require TWO types: One to deal with 
the swapping and then your "native" type where you save your swapped state.  
This now means you have to maintain two separate structs/classes when only one 
is needed.  

3) The fact that the endian types provide operators gives the impression that 
it's ok to operate on them.  I don't agree with that design choice, as I think 
the operation of endian swapping and operating on the data should be divorced 
from each other.  A less experienced user that you may end up not realizing 
what the hidden costs are and use the swappable types throughout the 
application, paying unnecessary overheads.  I would prefer for the library to 
be hard to misuse in that way; borrowing a phrase from python, "explicit is 
better than implicit".  This may be simply my opinion but I believe that 
forcing the user to do the explicit swap<>() leads to better separation of 
concerns for the application.

> Also, network-byte-order isn't the only "correct" over-the-wire byte order. 
> Some of us still believe that little-endian is better. (Don't take the 
> bait). ;o)

I code for several different platforms, some of which are little and some of 
which are big endian so I am completely agnostic to this issue and so is my 
library. (I am not sure whether there was something I said that made you think 
otherwise).

There are four types of swap in the library:
- little_to_machine
- big_to_machine
- machine_to_big
- machine_to_little

and each one of these can be used with swap<>(), swap_in_place<>() and the 
endian iterator.  

I hope you see that I don't prescribe any "network" order - it really is not 
my place to do so.

> Since the endian issue is larger than network-byte-ordering, I would suggest 
> removing any such references.

Again, I am not sure what you're referring to but if I'm missing something, 
please point it out.

Thanks!

Tom