At 02:04 PM 2/14/00 -0500, you wrote:
>Am I off base worrying about using typedef'd types when storing preferences?
>I don't want to worry about a new version of my program failing to load
>preferences because of a compiler change down the road changing the size of
>the structure.
>
>Would you do this:
>
>struct AppPrefsStruct
>{
> UInt optionOne;
> ULong optionTwo;
> Boolean switchOne;
>};
>
>Or this:
>
>struct AppPrefsStruct
>{
> unsigned short optionOne;
> unsigned long optionTwo;
> unsigned char switchOne;
>};
>
You would think that the second version would be correct in more
situations, wouldn't you? And it usually is (unless you go messing about
with some 64 bit compilers (hello, whats this "long long" thing? Just use
"hyper" like 'normal' people)). The big problem comes in when you start
using the "int" type, which can be either 16 or 32 bits, depending on the
compiler.
For this reason, Palm decided to use UInt, and Int etc, which are both
obviously 16 or 32 bits. The intention was too give the developer an
unambiguous type that was and always would be a certain number of bits
wide, no matter what compiler you used. Of course, they didn't suceed the
first time - it's still named ambiguously, but at least you know it will
always be the same width, no matter compiler you use....assuming the macros
are correct for the compiler you're on.
Then, simply for the sake of consistancy, they proceeded to make the mess
worse by creating all sorts of fun user defined types for things that were
already unambiguous, like "short" and "char" (oops, to some people char is
ambiguous, but thats a different story). Maybe they really did it for and
shorter names ("UShort" instead of "unsigned short"). The problem was that
one or two of the types had odd, unseen side effects. For instance, "const
CharPtr" is not the same as "const char *".
Happily, Palm has seen the error of their ways and decided to try again.
In the future, you can look forward to unambiously named, constant width
base types and complex types that behave they way they should. Just make
sure you program your applications exactly the way the majority opinion
tells you to and everything will be hunky-dory.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
