Hi all,
In the Mac OS, we have a concept of a FourCharCode, which is essentially a UInt32 except that it often has values that are made up of four characters. In Mac OS compilers then, the UNSIGNEDLONG (Cardinal attribute( size = 32 ))is compatible as a special case with constant strings of four characters.
In GPC, we've implemented FourCharCode = packed array[0..3] of char which works for most things, but it is not possible to do a case statement of this type, nor is it possible to cast between UInt32 and FourCharCode (which would provide a workaround, as the case statement could case the value and constants to UInt32 (except GPC does not allow casting in the case constants part, but even that can be worked around).
So basically, I'm looking for recommendations as to the best way to implement compatibility with this inside GPC, and/or the best extensions to GPC to allow compatibility with this sort of code.
A typical example might be:
const typeBoolean = 'bool'; typeChar = 'TEXT'; typeSInt16 = 'shor'; typeSInt32 = 'long'; typeUInt32 = 'magn'; etc
So it ends up being used as an extensible enumerated type if you like. Anyway, this concept is used all over the Mac OS API, so it is important to have reasonable compatibility for writin Mac OS applications.
Ok, so can anyone think of the best way to get this functionality?
Changing FourCharCode = UInt32 is probably better since the concept behind it is as a fixed size low cost use, and it is essentially never used as a string as such. The problem then comes from the fact that you can't case the constants above to UInt32's, eg:
typeBoolean = UInt32('bool');
this doesn't work.
One possibility might be to extend BP's # character hack to work with quoted strings in reverse, so #'bool' would return an unsigned integer constant equal to ((((ord('b)*256)_+ord('o'))*256+ord('o'))*256+ord('l').
Another might be to extend ord to allow ord('bool'), or perhaps ord4('bool').
I can hack the universal interfaces to convert to a UInt32 manually:
const typeBoolean = $626F6F6C;
but that looses a lot in the translation and puts a large onus of work on the end users for all the constants like this that they create.
I'm certainly open to hear of any existing GPC solutions that we could use instead.
Any ideas or comments?
Thanks, Peter.