Boost logo

Boost :

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

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.



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