Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 337
  • Last Modified:

D3. Longints in a record

More in the saga of converting D1 to D3.
Under D1 a variable of type longint gave 32 bit fields in a record. Under D3 it does not. The original file of records created under D1 cannot be read under D3 when the type is longint or integer. If I cheat and declare the type as array[1..4] of char the actual data in the file cannot be read of course  but it is in sync where with the longint it slips out of sync, so I'm convinced that the longint is not allocating 4 bytes in the record.
How do I declare an integer type that is 32 bits long?  
0
frog
Asked:
frog
1 Solution
 
interCommented:
Hi,
This actually happens because of two facts. 1 - Integer to Integer incompatibility between 16 bit and 32 application 2 - usage of packed records.
1 - ABOUT 32bit integer formats
There are two formats called BIG ENDIAN and LITTLE ENDIAN when storing bitfields(I may mix one and other but the idea is as follows): Lets consider and example:
The big endian is the linear storage of the bytes from most significant to least significant. Thats what the human beigns expecs:
Longint = 5
Hex = $00000005
BIG END. = $00000005
LITTLE END $05000000
So the algorithm for converting big endian to little is
* Swap the high and low words
* then swap each byte in high and low words
So in general:
BIG END = $XXYYZZPP
LITTLE      = $PPZZYYXX
2 - ABOUT packed reserved word
if you declare the following in Delphi 2.0+ you see that it occupies 4 bytes instead of one
TByte = record
  x : byte;
end;
To make it occupy the correct size use
TByte = packed record
  x : byte;
end;
I think this is one cause to the problem
------
In short using longint in both D1 and D2+ with packed record should solve the problem. So declare your record as follows in both of the compilers
TMyRec = packed record
  x,y : longint;
end;
Regards, Igor
0
 
BlackManCommented:
Actually, LongInt is 32 bit long. I guess that your problem comes from a D2/D3 compilersetting, "Aligned record fields" (project options / compiler [code generation])
When this is checked, fields in a record are aligned at even adresses to make it faster for the CPU to fetch the data.  But this means, that there is a possibility of "extra" bytes in your record and that's why your recordstructure in memory is larger than the one (D1) on disk.
0
 
frogAuthor Commented:
Thanks BlackMan, that fixed it and will stop it happening again.

Inter your suggestion of packed record was the same thing of course. I'll post an empty question for you so you can answer and also get points.

I guess I need to find a FAQ on the differences between D1 and D3, the manual doesn't give any clues.

0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now