From: "cbruner" <[EMAIL PROTECTED]> (as part of a possibly off-topic discussion about structure byte-alignment) > ... seems to me to be very byte centric. The only difference between reading at > an even boundary and odd one is one bit. The as far as the boundaries being > set up as dwords/words/bytes is just a matter of convenience, mainly for > programmers. > Nope, it's _in_convenient for programmers, done purely for processor speed. Even the processors that allow non-word oriented data explicitly document this as slow and to be avoided. And, since it generally can be avoided, anyone that packs a structure array to an odd offset is producing a bad design because this has an unknown speed and code complexity hit. Hell, half of the quad-byte aligned structures out there have a chance of failing on the new 64-bit processors, a google search will show you the problems people are having with alignment so it's not something you want to avoid thinking about.
After all, if you're accessing an indexed store written by a different processor issues such as endianness and byte-alignment have a fair chance of making your goal of mapping the processor-independent disk-based index directly to an in-memory array optimistic and unlikely. I agree that sometimes you get handed stuff designed by someone who didn't think past the end of their desk but I'd be more likely to point the 'bad design' finger at whoever handed you that data structure, not the designer of the processor you happen to be compiling for at the moment. Me, I'd have built the index as two arrays, one with the keys and one with the offsets, each of which would then be correctly aligned for whichever processor it was loaded onto. Although I guess that is just as likely to introduce some sort of problem somewhere, but that's optimisation for you. It's never free. Are we off-topic for this list yet? :-) Chris Tutty -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
