Überladene Funktionen - Delphi erkennt keine Eindeutigkeit?

[RSE]

Hallo!

Ich arbeite mit Delphi 5 (nicht 2005). Dort habe ich folgende überladene Funktionen deklariert:

Delphi-Quellcode:

    function BestellGrpSendExist(Typ: Integer = 0): Boolean; overload;
    function BestellGrpSendExist(aTyp: array of Integer): Boolean; overload;
    function BestellGrpSendExist(ProdNames: array of string; Typ: Integer = 0): Boolean; overload;
    function BestellGrpSendExist(ProdNames: array of string; aTyp: array of Integer): Boolean; overload;

Beim Aufruf von
BestellGrpSendExist(['bla','je'],[21,22]) meldet Delphi:

Code:

[Fehler] CCCHemopharm1003Ergebnis.pas(1145): Doppeldeutiger überladener Aufruf von 'BestellGrpSendExist'

Ich kann mir das nicht erklären. In meinen Augen ist der Aufruf eindeutig. Vielleicht weiß ja einer von Euch woran das liegt?

[himitsu]

Was passiert, wenn du mal die Defaultwerte (=0) in den Deklarationen wegläßt?

[uligerhardt]

Hmmm, ist in D2007 immer noch so. Das kann ich mir auch nicht erklären. Wenn ich die BestellGrpSendExist(aTyp: array of Integer)-Überladung auskommentiere, geht's.
Vielleicht kannst du die Überladungen ohne ProdNames entfernen und in ihren Aufrufen [] als ersten Parameter übergeben?

[RSE]

Also die Funktionen sind historisch gewachsen und rufen sich auch gegenseitig auf, ich werd also probieren müssen, was ich "umstrukturieren" kann.

Danke!

[himitsu]

Tja, wenn man mal genau hinsieht, wo der Cursor steht, nach/nei dieser Fehlermeldung, dann wird es klar.

Es wird direkt nach dem [ geprüft ob es "irgendwelche" Arrays gibt und da es mehrere Arrays gibt, kann sich der Kompiler nicht entscheiden, da er den Inhalt des Arrays wohl erst später auswertet und so noch nicht weiß was es für ein Array wird ... nun findet er aber mehrere Array-Deklarationen und muß aufgeben.


Ein Umweg wäre ['bla','je'] nicht als direkte Konstante, sondern über eine externe Array-Konstante/Variable zu übergeben-

[uligerhardt]

Zitat von himitsu:

Tja, wenn man mal genau hinsieht, wo der Cursor steht, nach/nei dieser Fehlermeldung, dann wird es klar.

Es wird direkt nach dem [ geprüft ob es "irgendwelche" Arrays gibt und da es mehrere Arrays gibt, kann sich der Kompiler nicht entscheiden, da er den Inhalt des Arrays wohl erst später auswertet und so noch nicht weiß was es für ein Array wird ... nun findet er aber mehrere Array-Deklarationen und muß aufgeben.

Bin grad zu einem ähnlichen Schluss gekommen:

Delphi-Quellcode:

procedure P(const AStrings: array of string); overload;
procedure P(const ANumbers: array of Byte); overload;

und z.B. P(['bla', 'je']); führen zum gleichen Fehler. Scheinbar wirft Delphi bei der Auflösung von Überladungen alle (offenen?) Array-Typen in einen Topf.

Edit: Dieser QC-Eintrag beschreibt ein verwandtes Problem. Den Fehler aus dem OP konnte ich in der QC nicht finden.

[himitsu]

Das Problem hab ich auch ständig mit überladenen Stringparametern.

AnsiString, UnicodeString/WideString und UTF8String ... gibt man nun direkt einen String 'xyz' an, dann kann sich Delphi nicht entscheiden.
Warum weiß ich nicht, denn es wäre doch sooo einfach:
Ist kein zu nutzender Typ vorgegeben (z.B. über eine Zielvariable oder einen eindeutigen Parameter), dann wird String genommen und schon wäre klar, welcher Aufruf genommen werden müßte
und/oder mam schaut, was an Möglichleiten zur Verfügung steht und versucht dann den angegebenen Typ irgendwo zuzuordnen und so auf ein eindeutiges Ergebnis zu kommen.

Hier ist es halt so, daß der Compiler das [ findet, nun schaut er nach welchen Typ das Array haben kann/muß, anhand von den Parametern (hier findet er leider mehrere und kann sich nicht entscheigen, da er zu doof ist jetzt mal in die Werte zu schauen und zu erkennen, daß dort Strings oder Integer enthalten sind und demnach dann nur noch eine Deklaration passen würde) baut er nun das Array auf.
Dann nimmt er sich erst den Inhalt vor und versucht die "Strings" in das Zielarray einzubauen. (wenn jetzt als einziges das Zielformat ein Integer(LongInt)-Array erkannt worden wäre und man übergibt Strings, dann hätte er beim String gemeckert, weil es kein Integer ist).

Es wünschen sich ja schon lange welche einen mehrphasigen oder zumindestens (wenn nötig) vorausschauenden Compiler, welcher dann solche Probleme nicht hätte.

[blackfin]

Öhm...bin noch nicht ganz wach, aber bei dem Aufruf übergibst du doch ein SET, kein Array (bzw. der Compiler nimmt da ein Set an):

BestellGrpSendExist(['bla','je'],[21,22])

[uligerhardt]

Zitat von blackfin:

Öhm...bin noch nicht ganz wach,

Sieht so aus.

Zitat von blackfin:

aber bei dem Aufruf übergibst du doch ein SET, kein Array:

BestellGrpSendExist(['bla','je'],[21,22])

Kuckst du hier unter "Open array constructors".

[himitsu]

['bla','je'] kann nur ein "offenes Array" sein, denn es gibt keine SETs mit Strings.
[21,22] könnte ein SET sein oder ein "offenes Array".

Darum schaut sich der Kompiler vorher das Ziel an, entscheidet dann was es nun werden soll und versucht danach die Werte dort einzufügen.