OOP, Vorlagen und Makros in mql5, Feinheiten und Anwendungen - Seite 10
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Schließlich könnte die Vererbungskette alles sein, was man will: sogar Interface<CBase>, sogar Interface<C<B<A<CBase>>>>, es gibt tonnenweise Varianten. Wir müssten CBase sequentiell in alle möglichen Varianten casten, was unrealistisch ist.
Ich erinnere mich, dass ich vorhatte, die Speicherung von Informationen über Schnittstellen im Klassenobjekt selbst zu implementieren und zusätzlich zu den bestehenden Schnittstellen-Pads unabhängige Schnittstellenklassen zu erstellen, die als Wrapper über unser Pad funktionieren würden. Doch dann kam ich zu dem Schluss, dass all dies unnötig und überflüssig war. In der Praxis habe ich noch nie eine Notwendigkeit gesehen, eine Basisklasse auf eine Schnittstelle zu casten, es macht einfach keinen Sinn. Die einzige Möglichkeit ist, herauszufinden, ob die Klasse diese Schnittstelle zu Debugging-Zwecken unterstützt, aber dafür brauchen wir kein Casting.
Meiner Meinung nach sollten wir die Schnittstelle in der Schnittstelle speichern. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ich habe dort etwas Code für ein Beispiel skizziert, aber ich möchte das Forum nicht mit zu vielen Buchstaben überfrachten.
Meiner Meinung nach sollte die Schnittstelle in der Schnittstelle selbst gespeichert werden. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ich habe dort etwas Code für ein Beispiel skizziert, aber ich möchte das Forum nicht mit zu vielen Buchstaben überfrachten.
Machen Sie weiter und veröffentlichen Sie es. Wie auch immer, es ist kein Unsinn, sondern ein Thema für Diskussionen. Aber in dem Thread, aus dem die Diskussion hierher verschoben wurde, wäre es unangebracht.
ok)
ok)
Warum gibt es die MethodeIComparer::Compare(CBase &op1, T &op2), wenn beide Argumente T sein sollten?
Und warum gibt es die MethodeIComparer::Compare(CBase &op1, T &op2), wenn beide Argumente T sein müssen
Ist es nur möglich, die gleichen Typen zu vergleichen? Ich gehe davon aus, dass dies nicht der Fall ist. Machen Sie T==CBase und es werden beide Argumente T )
Ah, ich hab's, dann hast du es ganz falsch verstanden. Die Klasse IComparer sollte in deinem Fall wie IComparer<T1,T2,CBase> sein. Dementsprechend wird auch die Methode:
Und wenn Sie die Klasse erben, werden Sie genau diese Methode überladen, und alles wird sich fügen.Ah, ich sehe, Sie haben es ganz falsch dann. IComparer Klasse in Ihrem Fall sollte wie IComparer<T1,T2,CBase> sein:
Und wenn Sie eine Klasse erben, werden Sie diese Methode überladen, und alles wird sich fügen.Und was ist die Bedeutung dieser CBase? Und warum müssen genau 2 Werte desselben Typs verglichen werden?
dynamische Besetzung zum Vergleich? sind Sie verrückt geworden?
eine rein virtuelle Funktion wird wie folgt geschrieben -virtual int CompareTo(Number *par) = 0 ;
ist es der Compiler, der verflucht wird, und nicht das selbst geschriebene Ausnahmesurrogat.
eine rein virtuelle Funktion ist wie folgt geschrieben -virtual int CompareTo(Number *par) = 0;
wird der Compiler anstelle des selbstgeschriebenen Ausnahme-Surrogats verflucht.
Ich brauche den Compiler nicht zu fluchen, weil ich ständig Basistypklassen (in diesem Beispiel Number) manipuliere. Wenn der Compiler darauf schimpft, läuft der Code gar nicht