Befindet sich Delphi noch auf der Höhe der Zeit?

[Sir Rufo]

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Delphi-Quellcode:

  &With.Block<string, Integer>(
    'foo',
    10,
    procedure( const s: string; const n: Integer )
    var
      i: Integer;
      sum: Integer;
    begin
      for i := 0 to 9 do
        begin
          sum := n + i;
          WriteLn( s + IntToStr( sum ) );
        end;
    end );

oder

Delphi-Quellcode:

TArray.ForEach<TCar>( 
  pool,
  procedure ( const car: TCar )
  begin
    &With.Block<TEngine>( 
      car.GetEngine,
      procedure ( const engine: TEngine )
      begin
        if (car.Manufacturer = TManufacturer.VW) and (engine.&Type = TEngineType.DIESEL ) then
          service.Schedule( car );
      end );
  end );

[BUG]

Zitat von Sir Rufo:

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Muss man ja auch nicht
Ich wollte eigentlich demonstrieren, dass man Blockvariablen durchaus einsetzen kann, um die Lesbarkeit zu verbessern (imho). Es wäre ja es nicht sonderlich schlimm gewesen die Variablen im Funktionskopf zu deklarieren, aber einen sinnvollen Wert haben die Variablen im Beispiel eh nur innerhalb des Blocks.

[Sir Rufo]

Zitat von BUG:

Zitat von Sir Rufo:

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Muss man ja auch nicht

Nein, natürlich nicht ... aber wenn man einem Feature X hinterherweint, dann muss man wohl wechseln oder sich mit dem arrangieren/vertraut machen was möglich ist.

Ich bin allerdings faul, und möchte auch nicht ständig irgendwo Variablen deklarieren nur weil ich durch ein Array laufen muss. Dann schreibe ich mir eben einen TArray.ForEach<T>(Action:TAction<T>) und kann mir diese Hilfsvariablen sparen.

[Stevie]

Zitat von Sir Rufo:

Dann schreibe ich mir eben einen TArray.ForEach<T>(Action:TAction<T>) und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT!

[Sir Rufo]

Zitat von Stevie:

Zitat von Sir Rufo:

Dann schreibe ich mir eben einen TArray.ForEach<T>(Action:TAction<T>) und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT!

Für 1.000.000 fette Records in einem Array benötigen die Aufrufe (von allen Records) 8ms - soviel Zeit habe ich so gerade noch
Mit mehr habe ich es nicht getestet, weil die Records so fett waren, dass der verfügbare Speicher nicht mehr ausreichte

Aber mit einem for in habe ich das auch getestet - das hat mir aber zu lange gedauert (>>1 Sekunde)

[Stevie]

Zitat von Sir Rufo:

Zitat von Stevie:

Zitat von Sir Rufo:

Dann schreibe ich mir eben einen TArray.ForEach<T>(Action:TAction<T>) und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT!

Für 1.000.000 fette Records in einem Array benötigen die Aufrufe (von allen Records) 8ms - soviel Zeit habe ich so gerade noch

Ich sag das nur, weil ich neulich eine Delphi Bibliothek ausgetestet habe, die von sich behauptet, besonders toll und nach funktionalen Paradigmen designed zu sein.
Für ein eigentlich sehr brauchbares Feature brauchte sie aber aufgrund dieser Architektur 500mal länger, als eine leicht optimierte Version dieses Features.

Zitat von Sir Rufo:

Aber mit einem for in habe ich das auch getestet - das hat mir aber zu lange gedauert (>>1 Sekunde)

Ja, das liegt daran, dass jeder Record in die Zählervariable gepackt wird und dafür der ganze CopyRecord Apparat loslegt

[Sir Rufo]

Zitat von Stevie:

Zitat von Sir Rufo:

Zitat von Stevie:

Zitat von Sir Rufo:

Dann schreibe ich mir eben einen TArray.ForEach<T>(Action:TAction<T>) und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT!

Für 1.000.000 fette Records in einem Array benötigen die Aufrufe (von allen Records) 8ms - soviel Zeit habe ich so gerade noch

Ich sag das nur, weil ich neulich eine Delphi Bibliothek ausgetestet habe, die von sich behauptet, besonders toll und nach funktionalen Paradigmen designed zu sein.
Für ein eigentlich sehr brauchbares Feature brauchte sie aber aufgrund dieser Architektur 500mal länger, als eine leicht optimierte Version dieses Features.

Das Problem kenne ich auch - darum habe ich es ja auch intern anders gemacht

So ist es maximal langsam (ohne Sleep zu verwenden):

Delphi-Quellcode:

procedure Slow<T>( values: array of T; Action: TProc<T> );
var
  v: T;
begin
  for v in values do // eine Kopie wird in v geschoben
    Action( v ); // v wird nochmal kopiert und dann erfolgt der Aufruf
end;

und so ist es eben fix

Delphi-Quellcode:

TAction<T> = reference to procedure( const Arg: T );

procedure Fast<T>( const values: array of T; const Action: TAction<T> );
var
  i: Integer;
begin
  // wir sind kein Copy-Shop als sparen wir uns jegliche Kopie
  for i := low(values) to high(values) do
    Action( values[i] );
end;

[AlexII]

Man muss die "Höhe der Zeit" erst definieren. VW war das auch mal. Lieber etwas älter aber dafür stabil.

[Sherlock]

Ich bin voll auf Hansas Schiene: Bugfixing! Bugfixing! Bugfixing! Das ist es was Delphi fehlt.
Diese Features, mit denen man die paar halbwegs wechselwilligen Java oder C# Coder versucht anzulocken, braucht keine Sau. Ehrlich. Dann lieber auf die zwei Leute verzichten und endlich mal Stabilität in die Sprache bringen, und mal ausnahmsweise versuchen eben nicht ein Release zu verkaufen, das nichtmal zuverlässigen 64Bit Code erzeugt. Das ist doch sowas von peinlich. Wenn man dann noch bedenkt, daß da vermutlich einer stundenlang drüber gebrütet hat, ob man dieses Bugfix allen oder nur den Subscribern zur Verfügung stellt, müssen einem doch die Haare zu Berge stehen.

Sherlock