New "features" in Delphi XE8

[Thaddy]

The most breaking one being:

"LongInt and LongWord are now platform-dependent integer types."

See: http://docwiki.embarcadero.com/RADStudio/XE8/en/What%27s_New_in_Delphi_and_C%2B%2BBuilder_XE8

[marcov]

I think that means they started giving meaning to longint and longword (e.g. size_t) or something and the ABI of aarch64 made that 64-bit.

Still it is a bit silly, they'd better define a new type that more clearly reflected the meaning (like native* in the past). I read through the docs you reference, and couldn't really find any meaning there, so maybe the reasons are FM related, rather than compiler+rtl.

[Thaddy]

Two new platform independent 32-bit integer types are introduced in XE8:
FixedInt: 32-bit signed integer type.
FixedUInt: 32-bit unsigned integer type.
FixedInt and FixedUInt ensure portability, better integration and interoperability with 32-bit and 64-bit platforms. These two new types ensure cross-language support between Delphi and C++ for your applications.

Frankly, I've lost the plot a bit with native, fixed, longint etc.
At least this one will break code. In that case, why not fix Native, integer and uint?

[serbod]

Very bizzare decision to name ordinal integer as FixedInt.
Why not Int32/UInt32 (same, as Int64/UInt64)?

[Leledumbo]

It's embarcadero. If anders is still there, he won't do such a stupid backward compatibility breaking changes.

[BeniBela]

FixedInt?

Omg, I hope you are not going to add this crap to FPC

[rtusrghsdfhsfdhsdfhsfdhs]

How about GetTypeKind for generics? So i can actually know the type at compile time?

[Thaddy]

For that to work you need RTTI and ultimately a Tpersistent descendant I guess.

[rtusrghsdfhsfdhsdfhsfdhs]

That's resolved at compile time not runtime no need for RTTI...

[Thaddy]

In that case your suggestion doesn't add much  value.
is, as, cast, assignments will do the job.

Why would you want that? You KNOW the type because YOU compiled the code.

[rtusrghsdfhsfdhsdfhsfdhs]

Heh why? Because if the compiler knows the type at compile time it can inline better? An example is quicksort algorithm and other algorithms. THATS WHY!

[marcov]

Two new platform independent 32-bit integer types are introduced in XE8:
FixedInt: 32-bit signed integer type.
FixedUInt: 32-bit unsigned integer type.
FixedInt and FixedUInt ensure portability, better integration and interoperability with 32-bit and 64-bit platforms. These two new types ensure cross-language support between Delphi and C++ for your applications.

Hmm, reading the C++ reference, then maybe they are comparable to our ctypes.cint and cuint then.  Maybe they are working on some arch where "C" int=8bytes or so.

[jc99]

My I remind you of the history of integer:
integer was supposed to hold that amount of bits the the processor could handle with one register.
e.G: on 16-bit machine it was 16-bit
on 32-bit big endian it was 32-bit big endian
and 32-bit little endian it was 32-bit little endian.
exception were the 64-bitter where integer stayed 32-bit.
So ...
Maybe they introduced FixedInt to ensure not only the bit-ness but also the endian-ness of a stored variable.
But since most modern prozessors can switch their endian-ness I personally see no need for this.
it's just another def in my jedi.inc:

Code: [Select]

{$ifdef fpc}
type FixedInt=longint; //[EDIT]
{$endif}


To me there are much more compelling things in Delphi which I still miss/haven't found in Lazarus.
e.G: Having a really good Project-Group-Management, to handle HUGE amount of Source-files, their test- and production-files (.lpi).

[marcov]

My I remind you of the history of integer:
integer was supposed to hold that amount of bits the the processor could handle with one register.
e.G: on 16-bit machine it was 16-bit
on 32-bit big endian it was 32-bit big endian
and 32-bit little endian it was 32-bit little endian.
exception were the 64-bitter where integer stayed 32-bit.

Integer is the base integer type of Pascal. The connection to register is implied, but only because the calculations of the base type must be fast. And a x86_64 has 32-bit (sub-)registers too, so that is not the problem.

Those processors can't switch endianess, but some are agnostic to it, iow the wiring to the chipset/memory determines endianess.  Those processors can't switch endianess runtime.

If the types had an associated endianess, there would be directives {$endianess} or so to signal  and define such types.

[jc99]

Integer is the base integer type of Pascal. The connection to register is implied, but only because the calculations of the base type must be fast. And a x86_64 has 32-bit (sub-)registers too, so that is not the problem.

Those processors can't switch endianess, but some are agnostic to it, iow the wiring to the chipset/memory determines endianess.  Those processors can't switch endianess runtime.

If the types had an associated endianess, there would be directives {$endianess} or so to signal  and define such types.

So we agree in the fact that integer, despite of it being a base-type of Pascal, changed it's representation over the years.
(I personally know, with BP7 and the ability/need  to write 32-bit-code I had to change a HUGE amount of code to be compatible to old data-files.)
With modern processors, I don't mean new representation of old architectures.
I am talking of ARM (e.G), Arcon did a good job designing this Beast. And ARM-processors are aware of endianess, and can act accordingly.
Emdarcadero just felt the need to introduce this new type.
About the x64 - I think you also got me wrong.
I am REALLY glad that integer stayed 32-bit for more than 20 years.
And I am also glad about that binary-datafiles are less important nowadays, thanks to CSV, XML and JSON (and lots of cheap storage-space ).