Hi,
I agree only partially on this one. If I want to know if two records of the same type have the same contents, they have to be identical byte-for-byte, even on strings length and record variants. If it is not the case, they are different and that's ok like this. The real problem here is the random content of the padding. It can make "equal" records different. At least it cannot make different records equal ;-)
I don't know exactly how SUN Pascal does this, but it works. By dumping records in binary format, I have always seen binary zeroes in the padded zones.
For sure I will have to generate functions to do the comparisons thus making the code bigger than it was. I already generated procedures to initialize them field by field, and conditional-compiled procedures to print their contents for debugging purpose since gdb cannot display them properly. Hard times...
Thanks for your suggestions.
Pascal Viandier pascal@accovia.com
On 10 Aug 2005, at 09:56, Pascal Viandier wrote:
Hi,
Pascal Viandier wrote:
When I say "compatible types", I say records with the same fields in the same order so I presume the padding bits and bytes would be done the same way.
Yes, but the pad bits and bytes can have random values ...
Ha! If only I could use FillChar() on the record before using it, there would be no problem! (Did you read the FillChar Suggestion thread?) This looks like a typical good reason to use it... I suppose the Extended Pascal's initial-state-specifier does not make initialization on padding bits and bytes neither.
Strings vary in length, record components take on different variants. Even if there were block-memory initialization, comparing whole records as memory blocks is hazardous. I wonder if the Sun compiler is really just generating code to do field-by-field comparisons? Knowing yoru own data and algorithm, I bet you could write a user program recordcompare function (you'd need one for each record type) taking account of your algorithm, that would usually only need to compare one field and thus would be very fast.
Willett Kempton