Hello,

I have a quick question: are there (m)any people here who store/load sets to/from files?

The reason is that we are considering to change the internal format of sets in FPC on big endian machines. The reason is that this would be necessary to allow byte-packing of sets (so that e.g. a set of 0..63 would only occupy 1 byte as opposed to 4 like is currently the case). An added advantage would be that this would make gdb (the debugger used by Xcode) display sets correctly on PowerPC's and other big endian machines.

I'm afraid this may cause backward compatibility problems, but if not too many people store sets in binary files, that fear is unfounded.

Thanks,

Jonas

Hi,

is it possible to keep a legacy reader in place ? That way it'll be easy to read old data and convert it to the new format and have little impact on historic data. If you happen to work on a big endian machine you could then do a once-off conversion.

Kind regards
Ewald Horn

Ewald Horn wrote

is it possible to keep a legacy reader in place ? That way it'll be easy to read old data and convert it to the new format and have little impact on historic data. If you happen to work on a big endian machine you could then do a once-off conversion.

We'd definitely provide a conversion function to convert from the old format to the new one, yes.

Jonas

Jonas Maebe wrote

I have a quick question: are there (m)any people here who store/load sets to/from files?

I do not mix sets and files, but I do mix sets and Single/Double in a record to decompose floating point numbers.

However, I don't see a big problem in converting my unit to accommodate a different internal set representation. (It might even simplify matters for me.)

I would think that in general the advantages you describe outweigh the disadvantages.

For purposes of converting between one representation and the other, it might be nice to provide a means to declare "old"sets, which use the current representation, _alongside_ the new sets, which use the improved representation. Then it would be fairly straightforward to write a conversion program that reads in the old format and writes out the new format.

Thanks for enquiring,

Tom

{$packset} support ?

It would be much simpler to simply provide conversion functions, because otherwise the code generator is going to become a real mess.

Jonas

A set of 0..63 requires 64 bits, doesn't it? So it would need 8 bytes, or am I mistaken?

Vincent

That does not allow for format conversion (even if it allows you to set the old set format).

Jonas

Vincent Snijders wrote

A set of 0..63 requires 64 bits, doesn't it?

Yes, my mistake.

Jonas

I was a bit brief, but I was thinking a bit about my usage of sets in the past, which was usually part of a record. So more about different sizes, not endian conversion.

It would then be possible to have the same record-with-set twice with different formats, and generate conversion routines for the datastructure.

However this would only matter if you have a gigantic number of these kind of records. So nevermind.

(For me no conversion needed btw, due to the Delphi<->FPC difference I stayed away from sets in files)

Another question, do you intend to fix the other size problem too? (another Delphi incompatability)

I mean by this sets of x..y having a size of roundup((y-z+1)/8) with z as x rounded down to the lower multiple of 8.

IOW, a set of 79..83 is two bytes in delphi.

Yes, this is the final goal. My approach was to make things completetly delphi compatible. This wouldn't cause much incompatibilities on little endian system with the old behaviour but on big endian systems it's a big mess.

Jonas Maebe wrote

Hello, I have a quick question: are there (m)any people here who store/load sets to/from files?

It would be nice to have an option like
{$MINENUMSIZE xxx}

so that binary compatibility with frequently used
bitmasks in C APIs is easier

kind regards,

Den Jean

Den Jean wrote

so that binary compatibility with frequently used bitmasks in C APIs is easier

Aren't bitpacked records/arrays more appropriate for that?

Jonas

Op Tue, 14 Nov 2006, schreef Jonas Maebe:

Semantically speaking, no.

Daniël

Sorry, I misread "bitmasks" as "bitfields". But using sets for C bitmasks is very dangerous, since sets are opaque and can differ from platform to platform (in practice only for endianess currently). It's the same for bitpacked arrays, in fact. Only bitfields in bitpacked records are identical as in C if combined with {$packrecords C}

Jonas