Difference between LongInt and Integer, LongWord and Cardinal

Question

In Delphi, what is the difference between LongInt and Integer, LongWord and Cardinal ?

and sometimes I find the usage of DWORD, what is it?

Are they consistent in all versions of Delphi? which one should I stick to?

I believe, asking online documentation for `DWORD` will give you an explanation right away. — Free Consulting, Jul 01 '14 at 12:04

score 10 · Accepted Answer · edited Jun 20 '20 at 09:12

10

In short: Longint and Longword are fixed size integers, the former signed, the latter unsigned, and both usually 32 bits in size. Their size is platform-dependent in XE8, but fixed size (32 bits) in XE7 and earlier versions.

Integer and Cardinal are not fixed size. They are so called "generic" integers (do not confuse this with generics, which is a different pair of shoes), i.e. they should preferrably be used when an integral type is required, regardless of the size. Depending on version and platform, the size of Integer and Cardinal may differ. Currently, they are the same size and type as Longint and Longword.

The sizes of the fixed size types don't differ between versions or platforms. You should use these types where you must interface with code or data from other sources than your own program, in other words, where exact binary compatibility is important, e.g. when calling API functions. Hence the use of types like DWORD, etc.

Note that current versions have aliases for types like Byte or Smallint. They are Int8, UInt8, Int16, UInt16, etc... up to UInt64. ISTM that these names are easier to remember than e.g. "Smallint" (16 bit signed) or "Shortint" (8 bit signed).

So use Integer and Cardinal whenever that is possible, since these are probably the ideal types for the platform and version. Use the fixed size types like Byte, Smallint, Longint or UInt64, just to name a few, when exact binary compatiblity with other data is required.

Update

Since there has been some confusion (see link near the top), and since nowadays not Longint and Longword are considered fixed size platform independent anymore, but, weirdly enough, Integer and Cardinal are considered fixed size, I more and more tend to use the (U)IntXX versions like UInt16 or Int32. One exception is my use of Byte, which I can't imagine ever changing its size (of 1).

And of course I will use Integer and Cardinal for anything that needs an integral type for which the size is not so important, e.g. for loop counters, etc.

edited Jun 20 '20 at 09:12

Community

1
1

answered Jul 01 '14 at 10:43

Rudy Velthuis

28,387
5
46
94

1

Integer and Cardinal never changes in the past (by fact). And never will change in future (by design). In latest documentations for XE6 it is clearly stated, there is only two platform-dependent integer types - NativeInt and NativeUInt. All other integer types, including "integer" and "cardinal" are platform-independent. – Andrei Galatyn Jul 01 '14 at 10:48
1

That is not true. Integer and Cardinal did not change to fit the native underlying registers, they remain 32 bit even on platforms with 64 bit registers. They have changed (from 16-bit TP and Delphi to 32 bit), and they may change for other platforms, if that makes sense. NativeInt and NativeUInt are guaranteed to have the native register size. – Rudy Velthuis Jul 01 '14 at 10:52
1

@Andrei Integer and Cardinal absolutely changed in the past, from D1 to D2 – David Heffernan Jul 01 '14 at 11:11
@David Ok, i mean era of Window x32 and later. BP/D1 are to old to be mentioned in context of Delphi. – Andrei Galatyn Jul 01 '14 at 11:27
@AndreiGalatyn `NativeInt` and `NativeUInt` are pointer sized rather than platform dependent. It so happens that the pointer size varies on different platforms, but semantically the association is with pointer size. On the other hand, it's plausible that `Integer` and `Cardinal` could change. They've changed in the past. It would be interesting to see a Delphi compiler on a 64 bit *nix platform. Platform memory model would suggest 32 bit integer and 64 bit long. I wonder what FPC does. – David Heffernan Jul 01 '14 at 11:33
@David I don't see any reasons why "Integer" may change in future. If you need integer type perfectly fit platform (better optimizations) - you should use NativeInt. Changes in other types will break all existing code, including code from Emb. So, they keep it unchanged at x64 platform, they marked it as platform-independent in help, there is no reasons to change it. For me it means that it will not be changed. – Andrei Galatyn Jul 01 '14 at 11:42
2

@AndreiGalatyn It's way more complex than that. 32 bit integer performance is better than 64 bit integer performance in a 64 bit process. Perf is not the reason. The purpose of `NativeInt` and `NativeUInt` is to get integer types that are the same size as a pointer. End of story. If in some future world, 64 bit integers perform better than 32 bit integers, then perhaps `Integer` might change. Or perhaps `Longint` will be 64 bit on 64 bit Mac/Linux, to match the platform memory model. I don't think that you can see into the future. – David Heffernan Jul 01 '14 at 11:46
@David: Emc is developing Delphi, so they don't need to see into the future, they are planning this kind of future. And i tend believe them in this question. NativeInt (not integer) is supposed to fit native integer type (not pointer) of CPU. IF there will be CPU natively operating 64-bit integers but 32-bit pointers, then pointer type will be 32bit, NativeInt will be 64bit (not equal to pointer!) and integer i believe keep same 4-bytes as mentioned by Emb. – Andrei Galatyn Jul 01 '14 at 11:54
2

@Andrei: you may not see any reasons, but Integer is generally the same size as integers in other languages on the same platform. If the size of integers on a particular (new) platform is not 32 bit, the size of Integer may change too. That is the difference between generic integer types like Integer, fixed size integer types like Longint and pointer sized integer types like NativeInt. – Rudy Velthuis Jul 01 '14 at 12:31
1

@Andrei: NativeInt is pointer sized, so you can store pointers in them. If pointers and integers have different sizes (this is so, on several platforms), it is supposed to be pointer sized, not integer sized. The integer size on most 64 bit platforms is 32 bit, and yet NativeInt is 64 bits in Win64, because a pointer is 64 bits. – Rudy Velthuis Jul 01 '14 at 12:33
@David: you are right. NativeInt's main purpose is to be able to store pointers in them, like, say, in the Tag property of a VCL component. Of course NativeInt can be larger than that, no problem, if anyone would be so stupid to build a CPU with 64 bit integer and 32 bit pointer registers. – Rudy Velthuis Jul 01 '14 at 12:37
@AndreiGalatyn Your last comment is quite wrong. You are confused between native integer size and pointer size. `NativeInt` is poorly named. It's better named over on .net where it is `IntPtr`. Or in C/C++ where it it `intptr_t`. I suspect that dreadful naming is the source of the confusion. – David Heffernan Jul 01 '14 at 12:41
It might be worth to use **fundamental types** term for fixed size types as per that late but nice concept. – Free Consulting Jul 01 '14 at 12:52
@David In mainstream CPUs pointer and native int have same size, so it is not so important actually, result is same. But changes in size of integer etc is not something they can change with simple decision, they will have to rework huge set of code, so i think it is best guarantee that they keep things "as is" for a while. So in this part i rely on promises from Emb. – Andrei Galatyn Jul 01 '14 at 12:53
@Andrei I really don't think you are getting this at all NativeInt is pointer sized. And very badly named. The native platform integer on windows, say, is always 32 bits. That is not pointer sized. – David Heffernan Jul 01 '14 at 12:59
@AndreiGalatyn And from the documentation: *The size of NativeInt is equivalent to the size of the pointer on the current platform.* That is its raison d'etre, but unfortunately the designers gave it the wrong name. – David Heffernan Jul 01 '14 at 14:35
@David Ok, seems you right and NativeInt introduced for compatibility with pointers mostly (then it is really badly named). But integer still in the list of platform-independent types, now not only de facto, but also de jure (Emb directly mentioned it in help). Maybe in feature something will change, but i prefer to rely on common sense and documentation, both tell me the same :) – Andrei Galatyn Jul 01 '14 at 15:16
It is a platform independent type, if used in a generic way. Simply use Integer, no matter the size is. Fact is that it has changed size once and that it may do that again. That is the purpose of generic integer types: to make them useful without much knowledge about internals like size, endianness, etc. That is what makes them generic. – Rudy Velthuis Jul 01 '14 at 17:09
@Andrei There's some irony in your comment about relying on docs. Delphi 5 docs said the ffg: "generic integer types are Integer and Cardinal; use these whenever possible, since they result in the best performance for the underlying CPU and operating system." **Only possible if platform dependent**. "ranges and storage formats for the **current** 32-bit Object Pascal compiler." "return a value of type Integer—which, in its **current** implementation, is equivalent to the 32-bit Longint." _If everyone relied on docs, there wouldn't be so much code likely to break if Integer did change size_. – Disillusioned Jul 02 '14 at 16:36
@Andrei PS: The current documentation states that the size of Integer is plaform-independent. In other words it will be the same size on Win32/Win64/MacOS/iOS/Android. **NOTE**: However, it doesn't exlude the posibility of it changing in a future version. E.g. Delphi XE14 ( expected to be released in 2018 ;) ) may decide to change the size of Integer to 64-bit (for whatever reason). So if you need to guarantee the size of some of your integers, you'd be well-advised to use the explicity sized types as per Rudy's answer. – Disillusioned Jul 02 '14 at 16:45
This answer is fundamentally wrong. Integer is the platform C++ int. LongInt is the platform C++ long int. – David Heffernan Apr 08 '15 at 20:20
The size of `LongInt` and `LongWord` changed in XE8, to be platform-dependent: http://docwiki.embarcadero.com/RADStudio/XE8/en/What%27s_New#Changes_in_LongInt_and_LongWord_Size_for_64-bit_iOS_Platforms – David Apr 08 '15 at 21:56
I know. A decision I don't like. – Rudy Velthuis Apr 11 '15 at 01:23
That was the only reasonable decision. `Integer` maps to `int`, `Longint` maps to `long int`. This has been true for all versions of Delphi. – David Heffernan Aug 26 '15 at 08:32
@David: IIRC, in the 16 bit versions, Longint mapped to 32 bit while Integer mapped to 16 bit. In 32 bit, both were the same, while long int was not the same as int. – Rudy Velthuis Sep 17 '18 at 14:15
@Rudy Yes. `Integer` maps to `int` and `Longint` maps to `long int`. – David Heffernan Sep 17 '18 at 14:17

score 3 · Answer 2 · answered Apr 08 '15 at 20:24

3

Delphi Integer is the underlying platform's C++ int.
Delphi LongInt is the underlying platform's C++ long int.
Delphi Cardinal is the underlying platform's C++ unsigned int.
Delphi LongWord is the underlying platform's C++ unsigned long int.

All four of these types are platform dependent.

On all supported platforms at the time of writing, Integer and Cardinal are 32 bit types. The types are platform dependent, it so happens that on all supported platforms the types are the same size.

On 64 bit *nix platforms, LongInt and LongWord are 64 bit types. On all other supported platforms, at the time of writing, the types are 32 bit types.

The key point is that these types are all platform dependent.

DWORD is a type alias used by the Windows API. Use it only when using that API.

Should you use Integer or LongInt? That depends on your use. As a rule, for interop use whichever type matches the C++ code. Otherwise, for most uses Integer is appropriate. Of course, this is a generic answer to your general question.

answered Apr 08 '15 at 20:24

David Heffernan

601,492
42
1,072
1,490

Obviously not quite true: On http://docwiki.embarcadero.com/RADStudio/Berlin/en/Simple_Types_(Delphi), Integer and Cardinal are *now* mentioned under **Platform-independent** (i.e. fixed size) types. – Rudy Velthuis Sep 17 '18 at 14:20
@RudyVelthuis That's probably a documentation mistake. And if it's not then it makes interop a little tricky. I mean, how are we expected to translate a C header file if there is no type that maps to `int`? – David Heffernan Sep 17 '18 at 14:22
@RudyVelthuis If you look back at historical versions of the documents then `Longint` was deemed platform independent. Of course that changed when they added support for a platform with a 64 bit C `long int`. If ever they support a platform with a C `int` that isn't 32 bits then they'll have to do the same with `Integer`. It would really help if the documentation writers understood the relationship between these types and the platform ABI (invariably determined by the native C tooling). – David Heffernan Sep 17 '18 at 14:28
I know the history. But *It Was Decided* that that doesn't count anymore. And with platform-independent I mean it keeps the size independent on the platform. But it was 16 bit on Win 3.x, and only yesterday, I looked at the Delphi 1 OP Language Guide and there Integer and Cardinal are listed as *generic*, i.e. **platform-dependent**, while fixed size types were listed as *fundamental*. In the D1 OPLG, they even mention what the size and value range of Integer and Cardinal will be on 32 bit platforms (!) – Rudy Velthuis Sep 17 '18 at 14:36
What I take it to mean is that at the moment Integer and Cardinal are the same on all platforms. I don't take it as a guarantee that this will be so forever. We saw that wasn't the case when 64 bit posix platforms were support and longxxx became 64 bit there. – David Heffernan Sep 17 '18 at 18:29
Historically, Integer and Cardinal were generic and platform-dependent ("generic"), while the others, like Shortint, Byte, Smallint, Word, Longint and Longword were considered fixed size ("fundamental"). That was changed and I don't think that was a good decision. – Rudy Velthuis Sep 17 '18 at 22:14
@Rudy I don't think anything changed. The documentation just means that on all platforms currently supported, these types are the same size. If ever they add a platform with a different sized C `int` then these types will magically become platform dependent. That's exactly what happened with Longint and longword. – David Heffernan Sep 18 '18 at 06:13
you may not think so, but things have changed. Just read the OPLGs for older versions.Also, the people who make such decisions have changed too. – Rudy Velthuis Sep 18 '18 at 06:31
@rudy I don't much mind what you think. You are welcome to your opinions on this, just as you are with winapi buffer lengths. – David Heffernan Sep 18 '18 at 06:40
It is not what I think. Just read the docs. Yours is an opinion, not mine. – Rudy Velthuis Sep 18 '18 at 07:13
@Rudy The docs used to say the same about `Longint`. Since that subsequently changed size, it's entirely plausible that `Integer` could do too. There is absolutely no promise that `Integer` won't change size in the future, just as there was previously no promise that `Longint` would not. And it duly changed size. As I said, you can believe what you want, but without a firm promise, that is just a belief. – David Heffernan Sep 18 '18 at 07:31
Also the docs are utterly hokey. They say. *The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord. Using these types whenever possible, since they result in the best performance for the underlying CPU and operating system, is desirable.* Blatantly false. An array of 64 bit integers is twice the size of an array of 32 bit integers. Since memory access dominates in many performance sensitive situations, performance will be worse with the array that is twice the size. Consider doing a linear search on such an array. – David Heffernan Sep 18 '18 at 07:33
@Rudy Anyway, I'm done here. This is tedious, each of us repeating ourselves. I don't mind if you think differently from me. Can't you accept that? It's just noise for future readers. – David Heffernan Sep 18 '18 at 07:33

score 1 · Answer 3 · answered Jul 01 '14 at 10:24

1

I suggest you check Delphi documentation for best explanation: http://docwiki.embarcadero.com/RADStudio/XE5/en/Delphi_Data_Types

answered Jul 01 '14 at 10:24

SilverWarior

7,372
2
16
22

That documentation says that a `Longint` is a 32-bit signed integer. That might lead someone to believe that a `Longint` is a 32-bit signed integer, when it is in fact a 64-bit signed integer. Source: [The Delphi Documentation](http://docwiki.embarcadero.com/RADStudio/XE8/en/What%27s_New_in_Delphi_and_C%2B%2BBuilder_XE8#Changes_in_LongInt_and_LongWord_Size_for_64-bit_iOS_Platforms). Confusing - i know; hence the original question. – Ian Boyd Jul 29 '20 at 18:40
1

`LongInt` is a 32 bit signed integer on Windows 32 platforms and 64 bit Windows platform but 64 bit on 64 bit iOS platform. This holds true even in latest [Delphi documentation](http://docwiki.embarcadero.com/RADStudio/Sydney/en/Internal_Data_Formats_(Delphi)#LongInt_and_LongWord). Also do note that in my answer I had linked Delphi Xe5 documentation which was still pretty valid at the time since Delphi XE6 got released just two months before the question was posted. But now you are referring to Delphi XE8 documentation which is documentation for Delphi version that hasn't exited at the time. – SilverWarior Jul 29 '20 at 19:22
Any way if you are trying to update your answer with latest information you should provide links to the documentation of latest Delphi version which is at this moment Delphi 10.4 Sydney – SilverWarior Jul 29 '20 at 19:25

Ian Boyd · Answer 4 · 2020-09-17T20:35:30.410

Short Version

| Type        | 16-bit platform | 32-bit platform | 64-bit platform  |
|-------------|-----------------|---------------- |------------------|
| Integer     | 16-bit signed   |            32-bit signed           | "generic type"
| Cardinal    | 16-bit unsigned |            32-bit unsigned         | "generic type"

| Longint     | 32-bit signed   | 32-bit signed   | 64-bit signed    | "fundamental type"
| Longword    | n/a             | 32-bit unsigned | 64-bit unsigned  | "fundamental type"
| Int64       | n/a             | 64-bit signed   | 64-bit signed    | "fundamental type"
| UInt64      | n/a             | 64-bit unsigned | 64-bit unsigned  | "fundamental type"
| Int32       | n/a             |            32-bit signed           |  
| UInt32      | n/a             |            32-bit unsigned         | 

| NativeInt   | n/a             | 32-bit signed   | 64-bit signed    |
| NativeUInt  | n/a             | 32-bit unsigned | 64-bit unsigned  |

| FixedInt    | n/a             |            32-bit signed           |
| FixedUInt   | n/a             |            32-bit unsigned         |

Long answer

We all know what they should have done:

| Type        | 16-bit platform | 32-bit platform | 64-bit platform  |
|-------------|-----------------|---------------- |------------------|
| Integer     | 16-bit signed   | 32-bit signed   | 64-bit signed    | "generic type"
| Cardinal    | 16-bit unsigned | 32-bit unsigned | 64-bit unsigned  | "generic type"

| SmallInt    |                   16-bit signed                      | "fundamental type"
| Word        |                   16-bit unsigned                    | "fundamental type"
| Longint     |                   32-bit signed                      | "fundamental type"
| Longword    |                   32-bit unsigned                    | "fundamental type"
| Int64       |                   64-bit signed                      | "fundamental type"
| UInt64      |                   64-bit unsigned                    | "fundamental type"

fundamental types don't change
generic types (aliases) do

But that's not what they did. So we are where we are.

Presumably Int32 will always be a signed 32-bit integer; but guarantees have been broken before.

Bonus Reading

Bonus Chatter

From the Delphi 5 help:

Integer types

An integer type represents a subset of the whole numbers. The generic integer types are Integer and Cardinal; use these whenever possible, since they result in the best performance for the underlying CPU and operating system. The table below gives their ranges and storage formats for the current 32-bit Object Pascal compiler.
Type      Range                    Format
--------  -----------------------  ---------------
Integer   –2147483648..2147483647  signed 32-bit
Cardinal  0..4294967295            unsigned 32-bit
Fundamental integer types include Shortint, Smallint, Longint, Int64, Byte, Word, and Longword.
Type      Range                    Format
--------  -----------------------  ----------------
Shortint  –128..127                signed 8-bit
Smallint  –32768..32767            signed 16-bit
Longint   –2147483648..2147483647  signed 32-bit
Int64     –2^63..2^63–1            signed 64-bit
Byte      0..255                   unsigned 8-bit
Word      0..65535                 unsigned 16-bit
Longword  0..4294967295            unsigned 32-bit
In general, arithmetic operations on integers return a value of type Integer—which, in its current implementation, is equivalent to the 32-bit Longint. Operations return a value of type Int64 only when performed on an Int64 operand.

Notice the "in its current implementation, is equivalent to Longint". The idea back then was that Integer would change; little did they realize that it was Longint that would change.

From the Delphi 1 User's Guide:

Data Types

Object Pascal has several data types built into the language. You can create variables of any of these predefined types. The following table lists the predefined data types:

Table 5.1 Object Pascal predefined data types

Integer: Numbers without a fractional part, within the range of –32768 to 32767. Requires two bytes of memory.

Shortint: Numbers without a fractional part, within the range of –128 to 127. Requires only one byte of memory.

Longint: Numbers without a fractional part, within the range of –2147483647 to 2147483647. Requires four bytes of memory.

Byte: Numbers without a fractional part, within the range of 0 to 255. Requires one byte of memory.

Word: Numbers without a fractional part, within the range of 0 to 65535. Requires two bytes of memory

From the Delphi XE6 Help:

Integer Types ================

An integer type represents a subset of the integral numbers.

Integer types can be platform-dependent and platform-independent.

Platform-Dependent Integer Types

The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt and NativeUInt. Using these types whenever possible, since they result in the best performance for the underlying CPU and operating system, is desirable. The following table illustrates their ranges and storage formats for the Delphi compiler.

Platform-dependent integer types
Type         Range                    Format                                  Alias  
-----------  -----------------------  --------------------------------------  ------------
NativeInt    -2147483648..2147483647  Signed 32-bit on 32-bit platforms or    Integer
             -2^63..2^63-1            Signed 64-bit on 64-bit platforms       Int64 
NativeUInt   0..4294967295            Unsigned 32-bit on 32-bit platforms or  Cardinal
             0..2^64-1                Unsigned 64-bit on 64-bit platforms     UInt64
Platform-Independent Integer Types

Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64.

Platform-independent integer types
Type         Range                    Format           Alias  
-----------  -----------------------  ---------------  ------
ShortInt     -128..127                Signed 8-bit     Int8 
SmallInt     -32768..32767            Signed 16-bit    Int16 
LongInt      -2147483648..2147483647  Signed 32-bit    Int32 
Integer      -2147483648..2147483647  Signed 32-bit    Int32 
Int64        -2^63..2^63-1            Signed 64-bit    
Byte         0..255                   Unsigned 8-bit   UInt8 
Word         0..65535                 Unsigned 16-bit  UInt16 
LongWord     0..4294967295            Unsigned 32-bit  UInt32 
Cardinal     0..4294967295            Unsigned 32-bit  UInt32 
UInt64       0..2^64-1                Unsigned 64-bit 

Notice how Integer and Cardinal were documented as platform dependent? Also notice how LongInt and LongWord were documented as platform independent?

score -1 · Answer 5 · answered Jul 01 '14 at 10:25

-1

Integer is a 32-bit signed integer type - Longint is an alias for this type. Cardinal is a 32-bit unsigned integer type - LongWord and DWORD are aliases for this type.

answered Jul 01 '14 at 10:25

Stefan Glienke

20,860
2
48
102

2

[`DWORD`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx#DWORD) is a Windows data type, not an alias... – TLama Jul 01 '14 at 10:47
@TLama In Delphi, `DWORD` is defined as an alias to `Cardinal` – David Heffernan Jul 01 '14 at 11:10
2

@David, well, it is defined so, but would you answer to *"sometimes I find the usage of DWORD, what is it ?"* with *"it is an alias for Cardinal"* ? I wouldn't. It is originally a Windows data type used for Windows API calls. And just for this purpose should be declared, I think. – TLama Jul 01 '14 at 12:02
@TLama fair point. Semantically it is as you say a 32 bit unsigned type – David Heffernan Jul 01 '14 at 12:13
DWORD was around before Windows. It was 2 WORDs. And a WORD back then was 2 BYTEs. All unsigned. Just saying. – David Schwartz Jul 01 '14 at 15:31
@RemyLebeau Looking at the documentation and code insight tells a different story. It tells me that a `LongInt` is in fact `Integer` and not the other way around. – Stefan Glienke Jul 01 '14 at 19:43
@Stefan: but not historically. This was changed recently (XE8, IIRC) Before, Integer officially mapped to Longint like Cardinal mapped to Longword in 32 bit Windows. Not so on 16 bit Windows. There, Integer mapped to nothing (there was no Smallint type yet) and Cardinal mapped to Word. – Rudy Velthuis Sep 17 '18 at 15:58

score -1 · Answer 6 · edited Jul 02 '14 at 00:19

-1

Previously there were fundamental integer types (should never change) and generic types, which theoretically could be different for different platforms, although integer types never actually changed. Now, in the documentation for XE6, there is a more logical, simple and clear definition of integer types, and only two platform-dependent integer types:

NativeInt
NativeUInt

All other integer types are platform-independent:

ShortInt 
SmallInt 
LongInt 
Integer 
Int64 
Byte 
Word 
LongWord 
Cardinal 
UInt64

For details, I suggest reading the "Simple Types" section of Help.

edited Jul 02 '14 at 00:19

Vector

10,879
12
61
101

answered Jul 01 '14 at 10:59

Andrei Galatyn

3,322
2
24
38

`Integer` is in the totally wrong list. You've misunderstood the concept of generic and fundamental types. – Free Consulting Jul 01 '14 at 11:17
@Free Any explanations, why do you think it is incorrect? – Andrei Galatyn Jul 01 '14 at 11:23
@Free I mentioned it in answer - there is no "generic" and "fundamental" integer types anymore in latest documentation from Emb. Only platfrom-dependent and platform-independent types. And "integer" defined as platform-independent. And it is same type even for x32/x64. So what do you mean? – Andrei Galatyn Jul 01 '14 at 11:32
But you've referred to generic concept in your answer. Ctrl+C,Ctrl+V from pre-mess version of documentation: *Generic integer types for 32-bit implementations of Delphi: Integer Cardinal* The [brilliant] idea behind generic type is what you use them when you do not worry about implementation (eg: loop counters) – Free Consulting Jul 01 '14 at 11:46
*...continuation...* , general expressions). Unfortunately, hasty migration to Win64 borked the whole concept. – Free Consulting Jul 01 '14 at 11:53
@Free Yes, when they migrated to w64, they have to change concept, because it was impossible to migrate all the code if size of integer (and other types) will change (according to concept of generic types). Even at that time there was huge legacy of sourcecode. But what's done is done, now we have to live with this. And now we have even more code based on types we have. I don't think Emb will change their mind again in order to change basic types (and rewrite all their own sourcecode). – Andrei Galatyn Jul 01 '14 at 12:04
They changed their mind once, what makes you think they will not do it again? The background of decision probably was a performance specifics of *current* IA-64 CPUs. I disagree what they *changed* the concept, by the way, for me it looks like they just *abandoned* the concept. – Free Consulting Jul 01 '14 at 12:15
@Free You can use any title, it doesn't change the result, concept "generic/fundamental" replaced by "platform dependent/independent" in docs. And integer keep same size for all (of course "current") platforms, including x32/x64. IA-64 is not supported by Delphi. – Andrei Galatyn Jul 01 '14 at 12:24
1

@FreeConsulting 64 bit Windows is IL32P64. What else were they going to do? They followed the platform. Nothing borked at all. They actually executed on Win64 very well indeed. And I speak as somebody delivering product on top on their Win64 compiler. And very happy with it too. – David Heffernan Jul 01 '14 at 13:29