Überladen von Methoden kollidiert mit Funktionszeiger-Parameter (Anonyme Methode)

[himitsu]

Versuch mal A.ToString(@IntToStr); ,
denn eigentlich willst du ja einen Funktionszeiger übergeben und nicht das Result einer Funktion.

Delphi will diesen Aufuf wohl an function ToString(const Separator: String): String; overload; übergeben und da fehlen beim IntToStr wirklich ein paar Parameter.

PS:

Zitat:

function ToString(const ToStrFunc: TToStringFunc: String; overload;

irgendwas stimmt dort nicht

[s.h.a.r.k]

Dein Vorschlag mit dem @IntToStr liefert mir die folgende Fehlermeldung -- hatte das auch schon ausprobiert:

Code:

[DCC Fehler] Testing.pas(1012): E2250 Es gibt keine überladene Version von 'ToString', die man mit diesen Argumenten aufrufen kann

Gibts auch andere Vorschläge? Würde man einen Default-Wert für anonyme Methoden definieren können, wäre das absolut kein Problem. Aber so kann ich nicht mal durch Änderung der Parameterreihenfolge dem Problem beikommen...

PS: Hab den Fehler gefixt -- muss beim Einfügen passiert sein

[himitsu]

Im reference to steckt ein Interface ... da könnte man es mal mit = nil als Standardparameter versuchen.

Du könntest es auch mal ohne Const bei der a. Methode probieren
und/oder die Stringvariante vor der Methoden-Variante deklarieren.

Ich hätte aber erwartet, daß @ funktioniert.

Denn was sollte man erwarten, wenn die Funktion eine a. Methode als Result zurückgiebt?

Delphi-Quellcode:

function Blub: TToStringFunc;
...

A.ToString(@Blub);  // Zeiger auf die Funktion
A.ToString(Blub);   // der Zeiger aus dem Result

Eine Automatik, welche ein implizites @, bei solchen Zuweisungen setzt, ist ja vollkommen OK,
aber das @, worüber man etwas eindeutig zuweisen kann, sollte dennoch funktionieren.

[s.h.a.r.k]

Ich kann dir schon gar nicht mehr sagen, was ich schon alles probiert habe und was nicht. U.a. das = nil als Default-Wert... Der Compiler meint, dass ich das nicht darf.

Das mit dem @ hatte ich auch schon probiert, ging nicht... Ich sag ja, ich check nicht, warum das nicht funktioniert. Und anonyme Methoden sind halt schon was geiles, daher will ich das Feature (also das reference to) eigentlich auch drin lassen.

Das mit dem const kann ich allerdings wahrlich noch testen, wobei ich dann den Unterschied nicht verstehen würde Aber man kann ja nie wissen, was der Compiler intern alles für Sachen macht.

[Namenloser]

Das Problem ist, dass du hast:

Delphi-Quellcode:

function ToString(const ToStrFunc: TToStringFunc): String; overload;
{…}
function ToString(const Separator: String): String; overload;

Der Rückgabewert von IntToStr ist String; deshalb nimmt der Compiler an, dass du die 2. Variante meinst, und bemerkt dann, dass ein Parameter fehlt.

[negaH]

Delphi-Quellcode:

function ToString(const  ToStrFunc: TToStringFunc; const Separator: String = ''): String; overload;
// function ToString(const ToStrFunc: TToStringFunc): String; overload;

letzte Methode komplett raus und erste Methode ein default Wert für letzten Parameter.

[s.h.a.r.k]

@negaH: Ich hätte aber gerne den ToStrFunc-Parameter optional Und genau das bekomme ich bisher leider nicht so wirklich gebacken. Mal schauen, vielleicht fällt mir ja noch was ein...

[negaH]

@s.h.a.r.k

Da das ein Compilerfehler ist kannst du den Compiler ändern oder musst eine Lösung nehmen die das Problem umgeht, oder du träumst weiter sorry wenn ich das so sagen muß.

Versuche mal meinen Vorschlag, ich habe ja nicht explizit gesagt das er auch funktionieren wird. Am Ende solltest du alle "überladenen Methoden und Funktionen" folgendermaßen betrachten. Aus Sicht des Benutzers deiner Schnittstellen die du jetzt deklarieren möchtest sollten alle überladenen Methoden und Funktion gleichen Names wie eine Funktionalität betrachtet werden, so als ob du nur einmal eine Funktion deklarieren würdest bei der du alle möglichen Parameterkombinationen in der Parameterliste definieren kannst. Denn genau das ist das Prinzip des Überladens.

Ich selber hatte nämlich exakt die gleichen Probleme wie du schon mit der D5 Version und meinen large Integer IInteger Objekten. Das von Borland benutzte Prinzip das man die Deklaration einer überladenen Funktionalität mit Hilfe meherer Funktionsdeklarationen erledigen muß führt zu mehreren solchen Problemen bei dem es dem Compiler schlicht unmöglich ist die Funktionen wieder an Hand ihrer Parameterliste wieder auflösen zu können. Verschärft wird das zusätzlich durch die Möglichkeit der Defaultwerte für die Parameter. Noch weiter verschärft sich das wenn man mit Objekten und überladenen Methoden in diesem Rahmen arbeiten möchte.

Überladene Funktionen können ein Segen wie auch Fluch sein, besonders wenn der Compiler Macken hat.

Gruß Hagen