Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk