
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
Jetzt geht's los.
So machen wir es.
Wenn eine statische Variable mit einer Konstanten initialisiert wird, dann wird diese Initialisierung in der globalen Initialisierungsphase durchgeführt, wie zuvor
Andernfalls (Aufruf oder Variableninitialisierung) wird eine statische Variable beim ersten Aufruf initialisiert (wie in C++), dieser Aufruf selbst wird in eine Bedingung mit impliziter globaler Variable/Flag verpackt, zum Beispiel
für MQL-Code:
Es wird der folgende Pseudocode erzeugt
Sie müssen sie trotzdem irgendwie in der Funktion trennen.
Nicht unbedingt und nicht immer. Ich werde keine Beispiele nennen, um das Thema nicht zu überfrachten.
So werden wir es machen.
Ja, ungefähr so. Denn MQL hat kein vollwertiges OOP. Außerdem gibt es eine Menge Bugs, die ich regelmäßig melde, aber ohne Erfolg. Und gegen die Bugs muss ich mich mit Krücken wehren, was soll ich machen.
Du bringst mich ganz durcheinander. Wenn in ... Ihre Worte lesen
Forum für Handel, automatisierte Handelssysteme und Strategietests
Eigenheiten von mql5, Tipps und Tricks
Alexey Navoykov, 2019.01.25 11:44
Wenn die Parameter von verschiedenen Typen sind, ist es sinnvoll, mehrere überladene Methoden mit den entsprechenden Typen zu machen. Man muss sie sowieso in Funktionen teilen, also ist es besser, sie in separate Funktionen aufzuteilen, als ein Durcheinander zu machen, das außerdem einen unpersönlichen Typ nimmt, d.h. man kann versehentlich alles übergeben und einen Kompilierungsfehler innerhalb der Bibliothek bekommen, was nicht gut ist. Oder vielleicht nicht einmal bekommen, was doppelt schlecht ist).
Kurz gesagt, in vollwertiger OOP sind Template-Funktionen eine Krücke (mit wenigen Ausnahmen).
MQL ist OK mit OOP, wenn sie Mehrfachvererbung hinzufügen(zumindest für Schnittstellen, weil sie in ihrer aktuellen Form nutzlos sind), wird es perfekt sein.
Schnittstellen sind also die Grundlage der normalen OOP, und Sie sagen, dass in MQL alles in Ordnung ist.
Schnittstellen sind also die Grundlage der normalen OOP, und dennoch sagen Sie, dass in MQL alles in Ordnung ist.
Die Grundlage der normalen OOP ist Polymorphismus, nicht Schnittstellen. Schnittstellen sind die Grundlage für eine bestimmte Klassenstruktur. Im Allgemeinen würde ich gerne über diese Themen sprechen, aber ich fürchte, dieser Thread ist nicht der richtige Ort dafür.
Die Grundlage der normalen OOP ist Polymorphismus, nicht Schnittstellen. Schnittstellen sind die Grundlage für eine bestimmte Klassenstruktur. Generell würde ich mich freuen, diese Themen zu diskutieren, aber ich fürchte, dieser Zweig ist dafür nicht geeignet.
Wir sprechen hier über die Besonderheiten der MQL-Sprache, und das Fehlen von Mehrfachvererbung ist ein recht charakteristisches Merkmal).
Ok, die Grundlage ist natürlich der Polymorphismus, aber ohne separate Schnittstellen ist er in der Anwendung nicht praktisch. Dies führt häufig zur Übergabe von Objekten als Template-Argumente anstelle von Schnittstellen.
Ich habe hier meine Variante beschrieben, mehrere Schnittstellen zu simulieren. Demnach kann eine Klasse deklariert werden als
Wir diskutieren über die Besonderheiten der MQL-Sprache, und das Fehlen der Mehrfachvererbung ist eine Besonderheit).
Ok, die Basis ist sicherlich Polymorphismus, aber ohne getrennte Schnittstellen ist es in der Anwendung nicht praktisch. Dies führt häufig zur Übergabe von Objekten als Template-Argumente anstelle von Schnittstellen.
Meine Variante, mehrere Schnittstellen zu imitieren, habe ich hier beschrieben. Entsprechend kann eine Klasse als solche deklariert werden:
Meiner Meinung nach ist nicht alles schlecht. Es gibt nicht so viele grundlegende Hauptschnittstellen in C#, dass ihre Methoden nicht auf eine grundlegende Oberklasse reduziert und dann vererbt werden könnten.
P.S. Etwas mehrfaches durch Konstruktionen wie <<<<>>>> zu implementieren ist ein bisschen mühsam. Es ist besser, Funktionen über Operatoren auszuführen, z. B. a==b ruft a.compareto( b ) auf, a[comparer]==b ruft comparer.compare(a,b) auf usw.