Recent

Author Topic: New "features" in Delphi XE8  (Read 17777 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: New "features" in Delphi XE8
« Reply #15 on: June 28, 2015, 09:53:03 pm »
So we agree in the fact that integer, despite of it being a base-type of Pascal, changed it's representation over the years.

Yes, and no, it was always architecture dependent, just not automatically register size.

That's also why Pascal, like most C compilers didn't go to 64-bit integers on 64-bit systems. Basically you are lugging around a lot of useless zeroes in most calculations.

Quote
(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.)

Quote
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.

PowerPC and MIPS too, but only on the chip or chipset design table. Not at runtime to my best knowledge. (and even if it were, then only as startup state, and after the startup it basically would be a different architecture as far as applications were concerned).

Quote
Emdarcadero just felt the need to introduce this new type.

Yes, but it might not be machine related, just something they need in e.g. FM in combination with some limitation of e.g. the new ARM64 iOS ABI.

Anyway, at this point it is all speculation.

jc99

  • Hero Member
  • *****
  • Posts: 553
    • My private Site
Re: New "features" in Delphi XE8
« Reply #16 on: June 29, 2015, 01:09:25 am »
Yes, and no, it was always architecture dependent, just not automatically register size.
"Architecture dependent", is the right word, I think there was never a 8-bit integer even on 6510-8-bit-machines.

That's also why Pascal, like most C compilers didn't go to 64-bit integers on 64-bit systems. Basically you are lugging around a lot of useless zeroes in most calculations.
I know there was a big debate about that in the delphi/pascal-scene.

The other "new features" are about a community-bar where you could buy more stuff, did I get that right ?
Please don't adopt these ...  ;D
OS: Win XP x64, Win 7, Win 7 x64, Win 10, Win 10 x64, Suse Linux 13.2
Laz: 1.4 - 1.8.4, 2.0
https://github.com/joecare99/public
'~|    /''
,_|oe \_,are
If you want to do something for the environment: Twitter: #reduceCO2 or
https://www.betterplace.me/klimawandel-stoppen-co-ueber-preis-reduzieren

Basile B.

  • Guest
Re: New "features" in Delphi XE8
« Reply #17 on: June 29, 2015, 04:44:36 am »
How about GetTypeKind for generics? So i can actually know the type at compile time?
This is a good feature they've added (since XE7 actually) however i don't like the syntax because you don't know that the branch is a compile time one.
In D for example you clearly know you're in a compile time branch because

instead of
Code: [Select]
if GetTypeKind(T) = tkInteger then
begin
end;

you have
Code: [Select]
static if (is(T == int))
{}

the static keyword changes everything while in Delphi you have no particular clue that indicates you're in a compile-time or a run-time statement.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: New "features" in Delphi XE8
« Reply #18 on: June 29, 2015, 05:11:23 am »
How about GetTypeKind for generics? So i can actually know the type at compile time?
Wait wait. GetTypeKind to write a type specific code?
It kinda sounds as an approach opposite to generic.

I can easily imagine generics with methods code written with huge case GetTypeKind () statements.

Basile B.

  • Guest
Re: New "features" in Delphi XE8
« Reply #19 on: June 29, 2015, 05:56:33 am »
How about GetTypeKind for generics? So i can actually know the type at compile time?
Wait wait. GetTypeKind to write a type specific code?
It kinda sounds as an approach opposite to generic.

You have a completly obsolete vision of Generics. The problem with FPC/Delphi generics is that they started as a feature for classes only. This limits something that could be much more powerfull!
Instead they should have been defined, since the begining, as a kind of "namespace" in which the parameters can be used, whatever is the language construct:

Code: [Select]
template <T,C>
  type PT = ^T;

  type TFoo = class
  end;

  type IBaz = interface
  end;

  function Baz(param: T): C;

 // and so on...
end;

Read this and will start understnading how FPC generics are retarded.
« Last Edit: June 29, 2015, 08:14:17 am by BBasile »

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: New "features" in Delphi XE8
« Reply #20 on: June 29, 2015, 07:28:28 am »
You have a completly obsolete vision of Generics. The problem with FPC/Delphi generics is that they started as a feature for classes only. This limits something that could be much more powerfull!
Instead they should have been defined, since the begining, as a kind of "namespace" in which the parameters can be used, whatever is the language construct:
...
Really? a whole module as a template? with parameters? I wonder the number of parameters need for such "namespace".
Surprisingly, someone finds less readable code more powerful.
Rest in piece, good-old structured programming.

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: New "features" in Delphi XE8
« Reply #21 on: June 29, 2015, 08:13:30 am »
Read this and will start understnading how FPC generics are retarded.
OK I tried to read the thing but it got me nowhere with D specifics and all that (I hate what I've seen so far to be honest) but since you seem to be a bit more familiar with the concept can you please tell me what is missing from the current implementation in FPC? keep in mind that templates are already possible in fpc with out generics with a number of parameters (if I understood correctly the "parameters" the document referes to). In any case what is it that you miss exactly?
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

Basile B.

  • Guest
Re: New "features" in Delphi XE8
« Reply #22 on: June 29, 2015, 08:28:29 am »
Not a whole module. I shouldn't use the word 'namespace'. I rather meant a "definition scope" where the parameters are valid.

what misses:
- template (as said upper: a defintion scope for a set of parameters).

Code: [Select]
template Foo<T>
  // declarations
end;

- global functions templates, this would allow to write algorithms for every array type.
Code: [Select]
function Fold<T>(arr: array of T; folder: function(p: T): T): T;
begin
end;

function indexOf<T>(arr: array of T; value: T): integer;
begin
end;

actually this is my bigest doleance. I've started to explore how it would be possible now (even if in term of performance it's a failure right now):
* https://github.com/BBasile/ArrayOps/tree/master/src

and i've spotted someone who would also need this (look at the monkey work this galérien has to do just because global generic func/proc miss !!!):
* https://raw.githubusercontent.com/Janilabo/MIMU/master/MIMU.pas

Maybe i'll add more later.

« Last Edit: June 29, 2015, 08:40:15 am by BBasile »

kazalex

  • New Member
  • *
  • Posts: 29
Re: New "features" in Delphi XE8
« Reply #23 on: June 29, 2015, 09:46:51 am »
I can easily imagine generics with methods code written with huge case GetTypeKind () statements.

It is possible to do it and rigth now, without GetTypeKind. PTypeInfo(TypeInfo(T)).Kind... But it works in runtime.
"If GetTypeKind(T) = .." Or "Case TypeKind(T) Of" is a constant expression, which can be used at inlined method for selecting one code branch at compile time.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: New "features" in Delphi XE8
« Reply #24 on: June 29, 2015, 10:31:00 am »
Yes, and no, it was always architecture dependent, just not automatically register size.
"Architecture dependent", is the right word, I think there was never a 8-bit integer even on 6510-8-bit-machines.

Most compiled systems are backported from mini computers (typically 16-bit or better) to micros. So the 8-bit situation was always had to be adapted.

Quote
That's also why Pascal, like most C compilers didn't go to 64-bit integers on 64-bit systems. Basically you are lugging around a lot of useless zeroes in most calculations.
I know there was a big debate about that in the delphi/pascal-scene.

I think I encountered it in 2002-2003, around the time that the compiler devs started working on the Itanium and later the x86_64 ports. Partially also because I had access
to an Alpha at work, and did some C on it.

Quote
The other "new features" are about a community-bar where you could buy more stuff, did I get that right ?
Please don't adopt these ...  ;D

We are only language and core libs compatible. Still, I think the base premise of structuring the installation of components is very good. I don't know how it works in practice (and I doubt Embarcadero will maintain it well for older Delphi versions in time). I don't have XE8, so I don't know how it works in practice.
 

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: New "features" in Delphi XE8
« Reply #25 on: June 29, 2015, 02:13:48 pm »
It is possible to do it and rigth now, without GetTypeKind. PTypeInfo(TypeInfo(T)).Kind... But it works in runtime.
"If GetTypeKind(T) = .." Or "Case TypeKind(T) Of" is a constant expression, which can be used at inlined method for selecting one code branch at compile time.
That's exactly the problem. Why would a generic need to know the type it implements. If there's a type specific code written in generic, then it limits generic use to these types only.

jc99

  • Hero Member
  • *****
  • Posts: 553
    • My private Site
Re: New "features" in Delphi XE8
« Reply #26 on: June 29, 2015, 04:37:21 pm »
That's exactly the problem. Why would a generic need to know the type it implements. If there's a type specific code written in generic, then it limits generic use to these types only.
That's not exactly true. You implement a special treatment for some types and another for everything else.
e.G:
Code: [Select]
If GetTypeKind(T) = .. then
  [...] // Handling for type ..
else
  [...]; // Handling for all other types ..
But you are right that these constructs limit the generality. So they should be handled with care.
OS: Win XP x64, Win 7, Win 7 x64, Win 10, Win 10 x64, Suse Linux 13.2
Laz: 1.4 - 1.8.4, 2.0
https://github.com/joecare99/public
'~|    /''
,_|oe \_,are
If you want to do something for the environment: Twitter: #reduceCO2 or
https://www.betterplace.me/klimawandel-stoppen-co-ueber-preis-reduzieren

kazalex

  • New Member
  • *
  • Posts: 29
Re: New "features" in Delphi XE8
« Reply #27 on: June 29, 2015, 06:23:33 pm »
That's exactly the problem. Why would a generic need to know the type it implements. If there's a type specific code written in generic, then it limits generic use to these types only.

This is not necessarily so.
Code: [Select]
Case TypeKind(T) Of
 tkDynArray: OptimizedForDynArrayCodeBranch;
 tktkInterface : VeryInterfaceSpecificCodeBranch;
Else
 UniversalAndMayBeUnoptimalCodeBranchForAllOthers;
End;

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: New "features" in Delphi XE8
« Reply #28 on: June 29, 2015, 06:49:07 pm »

This is not necessarily so.
Code: [Select]
Case TypeKind(T) Of
 tkDynArray: OptimizedForDynArrayCodeBranch;
 tktkInterface : VeryInterfaceSpecificCodeBranch;
Else
 UniversalAndMayBeUnoptimalCodeBranchForAllOthers;
End;

That doesn't explain the inline support. I think it is simpler, to avoid a systems of events to "handle" runtime types or different base classes for strings, objects (owner-free options) etc, like in fgl.

Delphi's generic support (and mostly, FPC's) was simply bad for cases where you had a base type for objects, valuetypes and automatied types. The handlers were always on a event/callback basis, incurring unnecessary overhead.


rtusrghsdfhsfdhsdfhsfdhs

  • Full Member
  • ***
  • Posts: 162
Re: New "features" in Delphi XE8
« Reply #29 on: June 30, 2015, 04:12:26 pm »
GetTypeKind is something like std::is_same.

What can it be used for? Well for comperator in QuickSort and other algorithm. For those who think this is stupid go benchmark qsort vs std::sort. Why rely on RTTI if you can get the information at compile time.

It can also be used to launch an algorithm for that specific type which it was optimized to.
« Last Edit: June 30, 2015, 05:21:53 pm by Fiji »

 

TinyPortal © 2005-2018