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