packed enumerated types?
frank at g-n-u.de
Fri Mar 28 13:25:11 CET 2003
Peter N Lewis wrote:
> >Packed subranges are a GPC extension not found in any other dialect
> >or standard (AFAIK). So far, there apparently hasn't been a need for
> >packed enums. I suppose they'd be rather easy to implement, but I'd
> >have to check in detail if needed.
> Mostly it just seems like a good place for better consistency.
Well, I don't mind either way.
> On a related not, is it possible to define a set that fits inside a
> Byte? Traditionally the text Style in Mac OS has been defined as
> something like
> set of (bold,italic,underlined)
> and fits inside a byte. But of course the poor C folks can't do this
> so they just use a byte and do all that bit twiddling. But it seems
> GPC requires 4 bytes for this, even if both the set and the subrange
> are packed. Is that correct? I presume there is no way to work
> around this (and no, I'm not asking for it as a feature, just double
> checking that it is not possible currently).
The sets routines operate on `MedWord' entities (= unsigned long in
C). It can be changed to Bytes (`TSetElement' in rts/sets.pas, but
also some bits in the compiler itself), but at the cost of
efficiency with larger sets.
Supporting both in parallel, depending on the set size is, of
course, not impossible, but extra work (you need 3-4 versions of
each routine -- big/big, big/small, small/small, for the
nonsymmetric ones also small/big), or let the compiler implicitly
convert small sets to one word before calling an RTS routine (like
it converts chars to strings when necessary, e.g.).
FWIW, we've thought about a more general set implementation,
including sparse representations for huge sets (so, e.g. `set of
Integer' would be possible). But at least for me (and apparently
most other people), that's not very important. (When talking about
various internal formats, strings are certainly much more
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
More information about the Gpc