Optionale (= vorbelegte) FunktionsParameter vom Type Record - Wie geht das?

[Andreas13]

Hallo Community,
ich möchte gerne Optionale (= vorbelegte) FunktionsParameter vom Type Record nach folgendem Muster verwenden:

Delphi-Quellcode:

Function p_ex(V, T, n: Extended; z: Extended = 1.25): Extended;
Begin
 . . .
End;

So funktioniert es natürlich einwandfrei.
Nun möchte ich einen vorbelegten Record als Parameter z übergeben:

Delphi-Quellcode:

Type
  TDRecord = Record
    X: Double;
    Y: Double;
  End;
      
Function p_Rec(V, T, n: Extended; z: TDRecord = (1.25, 2.5): Extended;
Begin
 . . .
End;

was der Compiler freilich ablehnt.

Hat jemand eine Idee wie ich den Parameter z mit Default-Werten vorbelegen könnte?
Geht das überhaupt?

Danke im Voraus!
Gruß, Andreas

[uligerhardt]

Als Defaultparameter geht das nicht, aber mit overload:

Delphi-Quellcode:

function p_Rec(V, T, n: Extended; const z: TDRecord): Extended; overload;
begin
 . . .
end;

function p_Rec(V, T, n: Extended): Extended; overload;
const
  z: TDRecord = (X: 1.25; Y: 2.5);
begin
  Result := p_Rec(V, T, n, z);
end;

[Andreas13]

Danke Uli für Deinen Vorschlag! Der einzige Schönheitsfehler ist nur, daß sich dadurch der Code verdoppelt und Redundanzen mit den bekannten Nachteilen entstehen.
Vielleicht kennt jemand einen noch besseren Weg?
Gruß, Andreas

[KodeZwerg]

Das Record wie eine Klasse aufbauen, also per "strict private" variablen und einer "Init" methode vielleicht?

[uligerhardt]

Zitat:

Zitat von Andreas13 (Beitrag 1490683)

Danke Uli für Deinen Vorschlag! Der einzige Schönheitsfehler ist nur, daß sich dadurch der Code verdoppelt und Redundanzen mit den bekannten Nachteilen entstehen.
Vielleicht kennt jemand einen noch besseren Weg?
Gruß, Andreas

Nö - die eine Routine ist ja nur ein dünner Wrapper, der die andere aufruft.

[Andreas13]

@KodeZwerg:
Die einfache herkömmliche Alternative wäre, in der rufenden Routine den Record z vorzubelegen

Delphi-Quellcode:

z.X:= 1.25; z.Y:= 2.5;

und z so als Parameter zu übergeben.
Daraus Klassen zu machen mit "strict private" Variablen und einer "Init" - Methode wäre eine Kanone auf ein Spätzchen, zumal ich etliche solche Funktionen mit Vorbelegung habe. Dadurch wäre sowohl der Code, als auch die Benutzung wesentlich komplizierter.

@Uligerhardt:
In manchen Fällen wäre es in der Tat nur ein dünner Wrapper, wenn die Werte in z linear in die Routine

Delphi-Quellcode:

p_Rec(V, T, n: Extended; const z: TDRecord): Extended;

eingehen, also wenn z.B. gilt:

Delphi-Quellcode:

p_Rec(V, T, n, z) := z.X*p_Rec(V, T, n) + z.Y;

Aber oft sind die Werte z.X und z.Y auf eine wesentlich kompliziertere, nichtlineare Art und Weise in der Funktion enthalten.

Man kann sich das etwa so vorstellen: Die StandardFunktion verwendet für die Berechnung einer komplexen Formel z.B.

Delphi-Quellcode:

z.X:= 1.25; z.Y:= 2.5;

. Es gibt aber noch Funktion_1, Funktion_2, Funktion_3 etc., welche mit der gleichen Formel aber mit verschiedenen z-Werten arbeiten können. In solchen Fällen wäre es kein dünner Wrapper mehr, sondern eine Duplizierung des Codes der Berechnungsroutine.
Aber für die linearen Fälle ist Dein Vorschlag mit

Delphi-Quellcode:

overload;

eine gute Lösung.
Danke & Gruß, Andreas

[uligerhardt]

Zitat:

Zitat von Andreas13 (Beitrag 1490696)

@Uligerhardt:
In manchen Fällen wäre es in der Tat nur ein dünner Wrapper, wenn die Werte in z linear in die Routine

Delphi-Quellcode:

p_Rec(V, T, n: Extended; const z: TDRecord): Extended;

eingehen, also wenn z.B. gilt:

Delphi-Quellcode:

p_Rec(V, T, n, z) := z.X*p_Rec(V, T, n) + z.Y;

Aber oft sind die Werte z.X und z.Y auf eine wesentlich kompliziertere, nichtlineare Art und Weise in der Funktion enthalten.

Man kann sich das etwa so vorstellen: Die StandardFunktion verwendet für die Berechnung einer komplexen Formel z.B.

Delphi-Quellcode:

z.X:= 1.25; z.Y:= 2.5;

. Es gibt aber noch Funktion_1, Funktion_2, Funktion_3 etc., welche mit der gleichen Formel aber mit verschiedenen z-Werten arbeiten können. In solchen Fällen wäre es kein dünner Wrapper mehr, sondern eine Duplizierung des Codes der Berechnungsroutine.
Aber für die linearen Fälle ist Dein Vorschlag mit

Delphi-Quellcode:

overload;

eine gute Lösung.
Danke & Gruß, Andreas

Meine Lösung kann Defaultparameter ersetzen, mehr nicht. Was du hier beschreibst, ginge ja auch mit Defaultparametern nicht.

[KodeZwerg]

Delphi-Quellcode:

type
  MyRec = packed record
    public
      procedure DoJob(const AValue: Integer = -1; const BValue: DOUBLE = 1.23);
  end;

var
  Form15: TForm15;

implementation

{$R *.dfm}

procedure MyRec.DoJob(const AValue: Integer = -1; const BValue: Double = 1.23);
begin
  //
end;

Habe es gerade mal ausprobiert und es compiliert ohne einen Fehler zu werfen.

[Andreas13]

@Uligerhardt:

Zitat:

Meine Lösung kann Defaultparameter ersetzen, mehr nicht. Was du hier beschreibst, ginge ja auch mit Defaultparametern nicht.

Doch Uli, es funktioniert bestens, denn beim Aufruf der Funktion kann ich die optionalen Parameterwerte überschreiben, d.h. mit neuen Werten belegen, mit denen dann gerechnet werden soll.

Hallo KodeZwerg,
ja, aber damit hast Du den Record in optional vorbelegte Teile zerpflückt. Das würde bei mir etwa entsprechen:

Delphi-Quellcode:

Function p_Rec(V, T, n: Extended; X: Double = 1.25; X: Double = 2.5): Extended;
Begin
 . . .
End;

Das habe schon lange so, was ohne Probleme funktioniert. Aber die Liste meiner optionalen Parameter kann auch mal deutlich länger sein bis zu 20 Elementen und mehr, daher dachte ich ein einen vorbelegten Record, weil dies übersichtlicher wäre.

Hinzu kommt andererseits der eigentliche Auslöser, der mich über die Parameterübergabe als vorbelegten optionalen Record bewogen hat: Das ist die Verwendung der mathematischen Bibliothek Neslib.MultiPrecision. Das sind die Beweggründe & Vorläufer dafür, damit Ihr das Ganze besser verstehen könnt:

1): High-Precision Floating-Point Types for Delphihttps://blog.grijjy.com/2021/05/05/h...#comment-29726
2): High-Precision Floating-Point Types for Delphi - Hilfe beim Linken von C object files https://www.delphipraxis.net/207850-...ml#post1488969
3): Hilfe beim Linken von C object files in in Delphi XE5? https://entwickler-ecke.de/viewtopic...&postorder=asc
4): und meine Beiträge zu:
https://github.com/neslib/Neslib.Mul...ue+is%3Aclosed

Ich versuche momentan meine früheren Berechnungen testweise von

Delphi-Quellcode:

Extended

auf die höhere Genauigkeit DoubleDouble (32 Ziffern) und QuadDouble (64 Ziffern) umzustellen.
Beide neuen Datentypen sind im wesentlichen Records:

Delphi-Quellcode:

Type 
DoubleDouble = record
  public
  X: array [0..1] of Double;
  . . .
End;
  . . .

QuadDouble = record
  public
  X: array [0..3] of Double;
    . . .
End;

Und diese Records kann man nicht zerpflücken, denn die Teile des Record-Arrays enthalten die weiteren Nachkommastellen, die nicht vom Benutzer, sondern von der Bibliothek intern nach aufwendigen iterativen Berechnungen bestimmt werden.

Damit ich meine zahlreichen "alten" Berechnungen, die viele vorbelegte optionale Parameter des Typs

Delphi-Quellcode:

Extended

enthalten auf

Delphi-Quellcode:

DoubleDouble

oder

Delphi-Quellcode:

QuadDouble

umstellen kann, müßte ich vorbelegte Records übergeben können, oder auf die Annehmlichkeit der vorbelegten optionalen Parameter verzichten...

Gruß, Andreas

[Uwe Raabe]

Nun, der Compiler lässt aber nun mal Default-Werte bei Record-Parametern nicht zu. Dann bleibt halt nur der von Uli beschriebene Ansatz mit overload.

Für den anfangs beschriebenen Anwendungsfall sehe ich da auch keinen wesentlichen Nachteil.

Delphi-Quellcode:

function p_Rec(V, T, n: Extended; const z: TDRecord): Extended; overload;
begin
 . . .
end;

function p_Rec(V, T, n: Extended): Extended; overload;
const
  z: TDRecord = (X: 1.25; Y: 2.5);
begin
  Result := p_Rec(V, T, n, z);
end;

Es lassen sich so Aufrufe mit und ohne z-Parameter schreiben, die auch korrekt ausgeführt werden. Wenn das nicht für deinen Anwendungsfall passt, dann zeig den doch mal. Es hilft ja nicht, wenn wir hier Lösungen für ein Problem suchen, was gar nicht existiert. Ich persönlich kann im Moment noch nicht sehen, wo es bei dir genau hakt.