A
Simon2 schrieb:
ich persönlich finde ja, dass "Performance" nicht das einzige Kritierium zur Beurteilung eines Features sein sollte.
Natürlich nicht. Der Punkt ist nur: Methodenzeiger in C++ und alle Tricks, die landläufig so benutzt werden, um mit ihnen und einem Objektzeiger Closures zu implementieren, sind viel klobiger, als sie sein müßten. Ein Methodenzeiger, der nicht an ein Objekt gebunden ist, muß darauf vorbereitet sein, auf eine herkömmliche Funktion, eine virtuelle Funktion, eine Funktion aus einer virtuell abgeleiteten Klasse und eine Funktion aus einer von mehreren Basisklassen, für die das Objekt eine andere Adresse hätte, enthalten zu können (die Liste erhebt keinen Anspruch auf Vollständigkeit ). Das ist zum Teil auch der Ballast, den sich C++ durch die Unterstützung von Mehrfachvererbung aufbürdet. Da ein Methodenzeiger nur die Methode, nicht aber das Objekt kennt, muß er all diese Informationen zur Laufzeit bereithalten und auch darüber entscheiden, wenn er mit einem konkreten Objekt aufgerufen wird.
Wenn du aber schon bei der Zuweisung einer Methode ein konkretes Objekt angibst - wie das bei Closures der Fall ist -, dann lassen sich die genaue Adresse der Funktion (z.B. VTable) und der passende Objektzeiger (z.B. bei mehreren Basisklassen) schon bei der Zuweisung feststellen. Im Closure müssen also nur ein Methoden- und ein Objektzeiger gespeichert werden, und der Aufruf ist ganze zwei Instruktionen lang:
push [Data] ; Objektzeiger
call [Code] ; Funktionszeiger
Simon2 schrieb:
C++ macht einfach keinerlei ABI-Aussagen - das kann man mögen (Freiheit für die Compilerentwicklung) oder nicht (ABI-Mix).
Das ist nicht das Problem. Problematisch ist, daß Lösungen, die mit C++-Methodenzeigern arbeiten, nicht binärkompatibel zu Delphis Funktionszeigern gemacht werden können, da sie in jedem Fall mehr als diese zwei Zeiger mit sich herumtragen.
Simon2 schrieb:
.... aber ist ja alles OK, wenn Du Dein Problem nun gelöst hast.
So ist es
