if really someone does this, it would be nice to have it in "standard" (FPC) mode also.

not just packed records, but also packed arrays:

packed array [ 1..2 ] of 0..15 { one byte }

packed array [ 1..8 ] of boolean { one byte }

Gerhard Scholz wrote

if really someone does this, it would be nice to have it in "standard" (FPC) mode also.

You will be able to activate it with a preprocessor switch.

The implementation of that would be completely separate from the support required for records. Also, since that is not required for compatibility, that will have a lower priority (unless someone submits a clean patch for it, of course)

Jonas

...

has been in Pascal (running on CDC), but Borland dropped it .

Gerhard

I am not trying to say that bit-level packing should have high priority (there are ways to work around it) but, since you mention compatibility, I would like to note that bit-level packed arrays are indeed a feature of UCSD, MPW, Think, MetroWerks, and GNU Pascal.

Another issue that comes to my mind is passing components of packed structures as actual variable parameters. Standard Pascal doesn't allow it at all, but it is more practical to forbid it only if the packed component uses bit-packing.

Regards,

Adriaan van Os

-----Ursprüngliche Nachricht-----
Von: "Adriaan van Os"
An: "FPC developers' list"
Gesendet: Samstag, 2. Juli 2005 04:01

I assume it would be very important to have it switchable in the source.

e.g.
p = packed record

            a : 0..100 ;
            b : boolean ;
         end ; { this should be "really" packed; 1 byte }

  q =  packed record
            a : 0..100 ;
            b : boolean ;
         end ; { this should be standard packed; 2 bytes }

so both versions could coexist, either by some new {$packrecords extreme} local compilerdirectives or e.g. STRICT PACKED RECORD or something similar (please: no new keyword!).

It came into my mind that nearly everything to integrate (for the moment I call them "strict") strict packed records/arrays is already in the compiler: the trick would be to see such a record or array as an object (some little inline "preprocessor" ?) with some static read/write/index properties (should work for objects (and maybe classes) also). The ref.pdf describes these properties only for classes, not for objects, but I tried it and found out that the compiler didn't read the documentation :-) , properties for objects seem to work o.k.

I assume the best point to incorporate this would be when the structure definition has been read.

Fields, which are not packable, should stay untouched.

A working example, which should make clearer what I mean, is in the appendix. The resulting code even looks quite compact. But of course in the ref manual it should be stated quite clear that using bit-packing is punished by additional execution time. On the other side there are enough situations where you have to look into bytes and have to to all shifts/masks yourself. Then bit-packing would be a help. Or you just have huge amounts of small data to store (the usual example is the array [ 1..1000000 ] of boolean).

Another issue that comes to my mind is passing components of packed structures as actual variable parameters. Standard Pascal doesn't allow it at all, but it is more practical to forbid it only if the packed component uses bit-packing.

The packed records or arrays, as they are implemented now, allow it to use their fields as var params (I just tried some simple examples) obviously.

In my proposal, as a side-effect, bit-packed fields are forbidden as var-params, but fields which are not bit-packable are allowed.

Gerhard

Gerhard Scholz wrote

>> You will be able to activate it with a preprocessor switch. I assume it would be very important to have it switchable in the source.

That is the case with preprocessor switches such as packrecords and friends, and I don't see why we would forbid it for bitpacking.

Jonas