Peter N Lewis wrote:
Unfortunately, both aren't suitable for case constants, as in Peter's example. (Though I don't know if they're frequently used that way.)
To speak for myself, no. I looked into a typical Mac OS program with 300.000 lines of code. It had 443 case statements, but none of them used FourCharCodes as case constants.
They become a lot more prevalent in Mac OS X carbon events code and NIB, as you use them for all the commands and status displays and controls and such.
In the CarbonEvents.pas unit, we could write something like this:
const kEventParamMenuRef : FourCharCode = 'menu'; kEventParamMenuRefWord = Word32( kEventParamMenuRef);
Now, you can use "kEventParamMenuRefWord" in case statements.
The alternatives are:
(1) Use a macro, but ... whatever macro you come up with, GPC won't propagate it to other units. So, how to define it once ? It must be available at the application level. Besides, macro's shouldn't be considered a regular programming concept in Pascal programs.
(2) Allow the type cast:
const kEventParamMenuRef = Word32( 'menu');
Frank Heckenbach wrote:
It would be nice if GPC were to allow i:=word32( 'abcd') also (e.g. in --macpascal mode), but this is not a necessity.
This would have to make an implicit decision about endianness,
Can't the compiler just look at __BYTES_BIG_ENDIAN__ and __BYTES_LITTLE_ENDIAN__ ?
Sure. But I mean we'd have to make a decision first how to handle it. Should it be always big-endian (like Peter's macro), or use the actual target's endianness (so it gets the same memory layout as the character array)? With the macro, this decision is left to the programmer. (Though it might not actually matter if the same conversion is used for all values.)
I would say, the first character of the character array should always come first in memory, which implies that the target's endianness determines the word value.
Regards,
Adriaan van Os