Prof A Olowofoyeku (The African Chief) wrote:
The perhaps obvious syntax
type Foo = (a = 3, b = 5);
is not a good idea since it's too close (too much read-ahead required) to:
type Foo = (a = 3) .. True;
Using `value' or `:=' instead of `=' might work, though.
Interesting. There are perhaps many reasons not to do this. But I would certainly benefit from such an extension. People might think that it is not important enough - but when you have thousands of lines of C header to translate, anything that helps is important. However, I don't feel strongly enough about this to be ready to defend it. So those who are ready to pounce can save their energy ;-)
Anyway, I think the semantical implementation would be rather easy since we can take it from the C frontend. It's also no question that it will be marked as a GPC extension. Only the syntax would be the question. (Same as the recently discussed record/enum extensions where we don't have a final conclusion yet, either, AFAIR.)
[...]
Maurice Lombardi wrote:
type tHighWord = packed record
One question - do the records need to be packed, or is that just a "good" thing?
With bitfields, they need do be packed (otherwise each field gets some whole number of bytes). Otherwise, I think it's better to not pack them.
Generally speaking, perhaps. With respect to the WinAPI, no. Specified sizes are "really needed" all over the place - function parameters, type declarations, function results, etc.
As I tried to explain, no (ABI).
This leaves only `Boolean(n)', and as I said, I severely doubt anyone ever uses an explicit bitfield larger than 1 bit with Boolean semantics in C (and if this happens once in a lifetime, the additional `<> 0' in Pascal is not worth the trouble of discussion).
I am not sure that I understand the distinction being made here about booleans. I think it is accepted that the WinAPI expects a 32-bit size for booleans.
As far as I could gather, it's the ABI which means that types such as WordBool (where C uses int) are probably at least as well suited if not better. ("Probably", i.e. if 64 bit Windows will stick to the interfaced WRT ABI.)
But again, I have no problem with the `Foo(n)' semantics, only the syntax is problematic (for at least 3 reasons so far).
If the choice is between packed subranges and a new, easy syntax, then I vote for the latter. Better still if it could be used in the way that Maurice has shown, in declaring fields of records (instead of having first to declare the type separately).
With a new syntax, this might well be possible. I.e., with the current syntax, I explicitly disallowed:
type Foo = Integer; Bar = Foo (16);
because I consider `Integer (16)' a special syntax that should not spread to each type.
An alternate syntax could be applied to any type -- though I wonder, what, e.g., `Byte (32)' should mean. ;-) The only possibly reasonable explanation would be the same as `Cardinal (32)'. Though C doesn't allow `char foo : 32' if the size of `char' is smaller than 32 bits.
As for the syntax, my suggestion was:
TypeOfSize (Integer, n)
Waldek suggested:
type foo = Integer attribute(Size(n),...);
I tend to prefer Waldek's (maybe even `attribute (packed (n))' since there is already a `packed' attribute in GCC, but without argument). The advantage is to avoid introducing a special identifier.
However, I think this should only apply to `type' definitions then (I think the same holds for GCC's `packed' attribute), not to `var' declarations etc. where it would implicitly create a new type.
Frank