Re: [boost] Portable binary integers [was generic polyvalent I/O]

From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-16 15:47:02

At 10:19 AM 11/16/2000 -0800, Darin Adler wrote:

 >Just a quick reminder about my "angle of attack" on this problem.

See Darin's http://www.egroups.com/files/boost/endian/endian.hpp. I just 
reloaded it as the previous copy seemed to contain some garbage.

This is a really interesting piece of code.  But it doesn't meet all the 
requirements I envision: see 
http://www.egroups.com/files/boost/endian/port_int_req.html

It also seems way overkill to use templates - it isn't like there are 
hundreds of valid argument combinations.  There are really only a very 
small number which make sense.  The template code is already way too 
complicated, and if you added error detection code to catch invalid 
combinations of template arguments, it would only get worse.  Just my 
opinion, of course.

 >I found that endian-specific integer types that supported close to the 
full
 >set of operations on integers helped me in projects where I was porting
 >existing code. I found that I could substitute endian-specific integer
 >types
 >for native integer types, and usually didn't have to make any other code
 >changes.

I've done that too, but without full-fledged arithmetic operators.  The 
implicit conversion operations were sufficient.  (I used an operator=(T) in 
addition to the operator T() you supply.)  IOW, they just convert to 
built-in types, and then the built-in operators work.

 >This is an argument for the "full-fledged arithmetic objects" approach,
 >although in practice I started with a minimal class and added to it as
 >needed in various projects. The idea was that it's safer to add to this
 >class than to make changes to the code I'm porting.

I'm not all that strongly against the "full-fledged arithmetic objects" 
approach, but I think it may sometimes result in slower code for complex 
expressions.  Maybe not, thought.

 >This worked *extremely* well on at least 3 major porting projects where I
 >had to make code that was unintentionally little-endian specific instead 
be
 >endian-neutral -- I think this approach saved me days of work each time.
 >Note that since some of the data structures were already defined 
implicitly
 >to be little-endian by the original (Windows) programmers data files, a
 >big-endian-only solution would not have helped me.

You already convinced me of that last spring.  Since then I remembered that 
there is one well-known format from a major GIS vendor that mixes 
big-endian and little-endian data in the same file!

--Beman