Dr.Bob on Delphi Language Enhancements

Delphi Clinic

C++Builder Gate

Training & Consultancy

Delphi Notes Weblog

Dr.Bob's Webshop


	Dr.Bob on Delphi Language Enhancements
See Also:	Delphi Papers and Columns

Borland Delphi 4 features a number of Object Pascal language enhancements, as usual. I've already published detailed papers on Default Parameters, Method Overloading and Dynamic Arrays. But there are some enhancements to native ObjectPascal types as well, especially when it comes to the built-in integer types Int64, LongWord and (changes to) Cardinal.

LongWord
Delphi 4 introduces a new 32-bits unsigned integer type, called LongWord, with a range of 0..2^32-1 (i.e. 4,294,967,295). As a direct consequence, the native unsigned 32-bit machine Word type called Cardinal, previously with a (31-bits!) range of 0..2G-1, now also has this 32-bits range of 0..4G-1 (finally, I might say).

Int64
Now that the "signed" Words are finally up-to-par with the unsigned integer types, Delphi 4 immediately introduces a new 64-bits integer type, called Int64, with a whopping range of -2^63..2^63 - 1 (I don't even know how much this is without executing the following program):

  program Delphi4;
  uses
    SysUtils, Dialogs;

  const
    MinInt64 = $8000000000000000;
    MaxInt64 = $7FFFFFFFFFFFFFFF;

  begin
    ShowMessage('Int64: '+IntToStr(MinInt64)+'..'+IntToStr(MaxInt64))
  end.

And even with the above dialog, it's hard to grasp how big these numbers are. Very big, that's for sure. And once you define an integer constant that's too big to fit in an integer (i.e. a signed 32-bits integer constant), then the compiler will automatically reserve an Int64 to hold this value.
Of course, everything comes with a price. In this case, it's speed. Since an Int64 is not a native machine integer, it has to be "simulated" by Delphi 4. And that means it takes more time than simply working with a 32-bits integer. How much more? Well, that's a topic for my Delphi 32-bits Efficiency session at BorCon, but for now it's enough to know that it's at least twice as slow...

Delphi 4 Integer types
Combining all this information with my previous Delphi integer types chart (from my "Porting Delphi 1.x code to 32-bits" paper, which needs to be updated for Delphi 4 right away), results in the following table:

Borland Pascal		Delphi 1.x		Delphi 2.x/3.x		Delphi 4
ShortInt	-128..127	ShortInt	-128..127	ShortInt	-128..127	ShortInt	-128..127
		SmallInt	-32768..32767	SmallInt	-32768..32767	SmallInt	-32768..32767
LongInt	-2G..2G-1	LongInt	-2G..2G-1	LongInt	-2G..2G-1	LongInt	-2G..2G-1
						Int64	-2^63..2^63-1
Byte	0..255	Byte	0..255	Byte	0..255	Byte	0..255
Word	0..65535	Word	0..65535	Word	0..65535	Word	0..65535
						LongWord	0..4G-1
Integer	-32768..32767	Integer	-32768..32767	Integer	-2G..2G-1	Integer	-2G..2G-1
		Cardinal	0..65535	Cardinal	0..2G-1	Cardinal	0..4G-1

Real
The original 6-bytes (or 48-bits) Real type was a left-over from the Turbo Pascal times, but had to be supported by Delphi (as 6-bytes floating point type) for compatibility reasons - at least that's what I think the reason was. However, being 6-bytes and an out-cast, the (old) Real type was never recommened for use (in fact, in previous versions of Delphi you could not even publish Real type properties, and should always have used the Single (4-bytes), Double (8-bytes) or Extended (10-bytes) floating point types instead.
Now, with Delphi 4, the Real type has been changed to 8-bytes, resulting in an identical type as Double. This also means that we can now publish the "new" Real (i.e. 8-bytes) type properties as well. However, be sure to check usage of the "old" Real in your code (for example when used as file or record fields).
Those of us who still rely on the "old" Real type can use the compatibility compiler option {$REALCOMPATIBILITY}.