What new features would you like to see in Delphi 13?

[dummzeuch 1392]

23 minutes ago, emileverh said:

I know it's a compiler problem, but why can they do it with classes and not with records....

Because a Class instance is a pointer.

And before you ask: You can actually have forward declaration for pointers to records.

[Uwe Raabe 1890]

44 minutes ago, emileverh said:

but why can they do it with classes and not with records....

You have already been told:

2 hours ago, Vandrovnik said:

In forward declaration of a class, compiler immediatelly knows the size of that type. For records, their size would be unknown in forward declaration.

 

[JonRobertson 39]

8 hours ago, Uwe Raabe said:

You have already been told:

10 hours ago, Vandrovnik said:

In forward declaration of a class, compiler immediatelly knows the size of that type. For records, their size would be unknown in forward declaration.

 

The Delphi compiler is also a single pass compiler, unlike C/C++. Being a single pass compiler is one of the reasons that Delphi builds projects much faster than a similar C++ project.

 

I would expect changing Delphi to support multi-pass compiling would be a huge task with few benefits. But I don't know much about writing a compiler. 

[Vincent Parrett 657]

14 hours ago, emileverh said:

forward declaration of records, just like a class

Embarcadero would need to move to a multi pass compiler to achieve this - something they have always resisted. I can understand this 10-15 yrs ago, but on modern hardware the compiler performance loss from multiple passes would not be that noticable.

 

Edit : FWIW - in a multipass compiler, forward declarations are not usually needed (Java, C# for example don't use forward declarations). 

Edited February 25 by Vincent Parrett
addition

[Attila Kovacs 617]

3 minutes ago, Vincent Parrett said:

compiler performance loss from multiple passes would not be that noticable.

I'd say they undo every change they did in the last 17 years and go back to the compiler speed of D2007.

 

Edited February 25 by Attila Kovacs

[Cristian Peța 94]

17 hours ago, emileverh said:

I know it's a compiler problem, but why can they do it with classes and not with records.... 

It's not a compiler problem, but record variables are not class variables and when you declare a record variable it is allocated automatically.

You enter into a infinite loop of circular allocation.

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;
  
var
  a: TRecA; //infinite circular allocation of memory

 

[Tommi Prami 123]

8 hours ago, Vincent Parrett said:

Embarcadero would need to move to a multi pass compiler to achieve this - something they have always resisted. I can understand this 10-15 yrs ago, but on modern hardware the compiler performance loss from multiple passes would not be that noticeable.

Even something like 1.5 pass compiler that would enable some functionality or extend existing would be cool to have...

-Tee-

[Uwe Raabe 1890]

23 hours ago, emileverh said:

forward declaration of records, just like a class

Actually there is a way to achieve that using generics:

type
  TRecB<T> = record
    FieldA: T;
    FieldB: Integer;
    FieldC: string;
  end;

type
  TRecA = record
    Secret: string;
  end;

type
  TRecB = TRecB<TRecA>;

 

[David Heffernan 2300]

3 hours ago, Cristian Peța said:

It's not a compiler problem, but record variables are not class variables and when you declare a record variable it is allocated automatically.

You enter into a infinite loop of circular allocation.

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;
  
var
  a: TRecA; //infinite circular allocation of memory

 

This isn't really a great example. The sort of thing that I want to do with records, but cannot, is this:

type
  A = record;
  B = record;
  
  A = record
    function foo: B;
  end;
  
  B = record
    function bar: A;
  end;

I can get round this using helpers right now, but I don't understand why I can't do this directly as above.

[PeterBelow 218]

On 2/25/2024 at 3:00 PM, emileverh said:

I know it's a compiler problem, but why can they do it with classes and not with records....

Because classes are reference type and records are value types. A variable/field of a reference type will always have a a known size, sizeof(pointer). A value type does have the size defined by the type and that would be unknown at the point of the foreward declaration. A one-pass compiler cannot handle that.

[Fritzew 51]

4 minutes ago, PeterBelow said:

A one-pass compiler cannot handle that.

And this is the problem. I think it is time for a two-pass compiler in Delphi. But the problem I see there is that Emabarcadero has not the power to switch.
If I see what Remobjects can do with her compilers.........

[David Heffernan 2300]

1 hour ago, PeterBelow said:

Because classes are reference type and records are value types. A variable/field of a reference type will always have a a known size, sizeof(pointer). A value type does have the size defined by the type and that would be unknown at the point of the foreward declaration. A one-pass compiler cannot handle that.

None of that applies to my example above. 

[Brandon Staggs 185]

1 hour ago, David Heffernan said:

None of that applies to my example above. 

Beg to differ. At the point you declare an instance of TRecA inside of TRecB, the compiler does not yet know how much memory a TrecA instance takes. 

 

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;

[David Heffernan 2300]

1 minute ago, Brandon Staggs said:

Beg to differ. At the point you declare an instance of TRecA inside of TRecB, the compiler does not yet know how much memory a TrecA instance takes. 

 

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;

That's not my example. Nobody wants to do this with a value type because it's a non terminating recursion. Have a look at my example code to see what I'm actually talking about. 

[Brandon Staggs 185]

1 minute ago, David Heffernan said:

That's not my example. Nobody wants to do this with a value type because it's a non terminating recursion. Have a look at my example code to see what I'm actually talking about. 

Ah, got it. Still, you want to return an instance of a type that is not yet defined for the compiler. Maybe you should be able to, I suppose. 

[Ian Branch 121]

Case on Strings.

i.e.

case myStringVariable of

'A': do something;

'Test': do something;

etc

end;

[mitch.terpak 5]

For Linux64 to not compile to something 5-20x slower then Windows.

Edited February 29 by mitch.terpak

[Dalija Prasnikar 1341]

23 minutes ago, mitch.terpak said:

For Linux64 to not compile to something 5-20x slower then Windows.

Forget about that. While there is always a possibility that speed may be slightly improved, slowness is a feature of LLVM backend.

[Stefan Glienke 1905]

3 minutes ago, Dalija Prasnikar said:

Forget about that. While there is always a possibility that speed may be slightly improved, slowness is a feature of LLVM backend.

If it at least would produce binaries that are faster than what classic compiler for Windows produces ...

But due to their currently super old LLVM version (hopefully they upgrade that once they are done on the C++ side which personally I could not care less about), they apparently had to turn off some important optimization steps which causes the binary produced by the Linux compiler to be approx as good as -O0 

[David Heffernan 2300]

18 minutes ago, Stefan Glienke said:

If it at least would produce binaries that are faster than what classic compiler for Windows produces ...

Delphi produces native code, and therefore is fast

[Vandrovnik 202]

32 minutes ago, David Heffernan said:

Delphi produces native code, and therefore is fast

Even native code may run slow, when compiler does not use registers efficiently, uses superfluous jumps etc.

[David Heffernan 2300]

12 minutes ago, Vandrovnik said:

Even native code may run slow, when compiler does not use registers efficiently, uses superfluous jumps etc.

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code.

 

We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. 

 

Yes, my original post was sarcasm.

[Vandrovnik 202]

24 minutes ago, David Heffernan said:

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code.

 

We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. 

 

Yes, my original post was sarcasm.

I was not sure about the sarcasm, but decided to reply, so that someone does not believe it blindly 🙂

 

[Dalija Prasnikar 1341]

2 hours ago, Stefan Glienke said:

But due to their currently super old LLVM version (hopefully they upgrade that once they are done on the C++ side which personally I could not care less about), they apparently had to turn off some important optimization steps which causes the binary produced by the Linux compiler to be approx as good as -O0 

Imagine how slow would compilation be with those optimizations turned on. 

 

I hope than newer LLVM could be faster, but I wouldn't keep my hopes up https://discourse.llvm.org/t/if-llvm-is-so-slow-is-anything-being-done-about-it/75389

[Stefan Glienke 1905]

13 hours ago, Dalija Prasnikar said:

Imagine how slow would compilation be with those optimizations turned on. 

I said this before and I say it again - nobody should care how long the compiler churns on producing a release config build.

 

Also: the FE is still written by Embarcadero and I don't know how much time is spent there compared to the LLVM BE and how much of that could be improved by tweaking some settings.

Given their usual attitude of "making it barely work" and leaving optimizing for later until everyone and their cat/dog complains and then waiting even a few years longer until tinkering around the edges I can only imagine how well done the FE is.

Also, keep in mind that the Windows compilers regressed heavily with all the new language features introduced in the past 15 years and that it was mostly due to the efforts of Andreas Hausladen that we gained back some of that speed in the recent versions while still being way behind what it could be imo.

 

Currently reading through the thread (not done yet but just leaving my thoughts as I go through) and this comment was interesting:

Quote

The way this breaks down varies from file to file, but the general rule of thumb is that clang frontend is the most time-consuming followed by IR optimizations, LLVM codegen, and clang codegen usually being tiny.
I’d say the frontend taking 50-60% of the time is close to average, with IR optimizations usually 20-30% of time.

Interestingly later someone comments that if you compile a different project it turns around into the opposite - and then there is this statement:

Quote

And I would tend to attribute much of the 9x compile time increase for the debug build to wrangling dwarf information, exacerbated by huge STL files.

This is something I have actually seen with the non-Windows Delphi compilers: when I throw some generic-heavy code at them they take a ridiculous amount of time to compile - and some of the optimizations done by Andreas Hausladen actually resolved around generics. I would not be surprised if such an issue still exists either in the BE or in the LLVM code when generating debug symbols due to all the long full-qualified type names.

Edited March 1 by Stefan Glienke