OOP, Vorlagen und Makros in mql5, Feinheiten und Anwendungen - Seite 5
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
Über Multi-Passing - übereilt, naiv gedacht, dass der Mikrokodex es erlauben würde
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
Ich verwende auch ausgiebig Vorlagen und Makros, betrachte aber freie Funktionen nur als zusätzliche (und im Allgemeinen unerwünschte) Architekturelemente. Wenn alle Implementierungen in Objekten verpackt sind und die Statik nur auf Klassenebene deklariert wird, treten lästige Fehler auf, außer dass es manchmal schwer ist, die Logik der korrekten Reihenfolge der Deklarationen zu verstehen, so dass der Compiler nicht flucht...
Es gibt hier also Variablen. Und bei den Funktionen, ja, die sind mehrfach übertragbar, also war alles richtig. Das Problem entsteht genau wegen der Reihenfolge der Initialisierung von Funktionen. Kurz gesagt, in C++ gibt es eine strikte Reihenfolge, die für Variablen, Funktionen und Typen gilt. Und in MQL ist alles anders.
Mehrere Durchläufe sind in jedem Fall schlecht - es kann zu Rekursionen, Deadlocks usw. kommen. Aber das Positive ist, dass es möglich ist. Deshalb nur klug, vorsichtig (d.h. Vorwärtsdeklaration), und nicht wie jetzt mit Multipass-Compiler - denn wenn für jede Funktion eine Vorwärtsdeklaration gemacht wird, schlägt diese Harke früher oder später auf Ihre Stirn.
Multipassing ist in jedem Fall schlecht - es kann zu Rekursionen, Deadlocks usw. kommen. Bei Pluszeichen ist es jedoch möglich, eine Vorwärtserklärung abzugeben. Deshalb nur klug, vorsichtig und nicht wie jetzt mit dem Multipass-Compiler - denn wenn für irgendeine Funktion eine Vorwärtsdeklaration gemacht wird, schlägt diese Harke früher oder später auf Ihre Stirn.
Ich stimme zu. Dieses Thema wurde bereits vor einiger Zeit diskutiert. Das ist es, was viele hier an der Sprache mögen - dass man sich nicht um die Reihenfolge der Funktionsdeklaration kümmert. Unnötig zu erwähnen, dass ich vor einiger Zeit selbst froh darüber war). Aber seine Langweiligkeit hat mich auf der positiven Seite irritiert. Aber mit der Erfahrung kommt das Verständnis.
Ich verwende auch ausgiebig Vorlagen und Makros, betrachte aber freie Funktionen nur als zusätzliche (und im Allgemeinen unerwünschte) Architekturelemente. Wenn alle Implementierungen in Objekten verpackt sind und die Statik nur auf Klassenebene deklariert wird, treten lästige Fehler auf, außer dass es manchmal schwer ist, die Logik der korrekten Reihenfolge der Deklarationen zu verstehen, so dass der Compiler nicht flucht...
Ich stimme zu, wenn in der OOP alles klar geregelt ist, dann werden nicht nur freie Funktionen nicht benötigt, sondern auch Template-Methoden.
Schablonenmethoden werden überall dort benötigt, wo man nicht einen Haufen sich wiederholenden Code schreiben will, sei es OOP oder nicht OOP. Freie Funktionen sind eine andere Sache - es handelt sich um unterschiedliche Programmierstile.
Schablonenmethoden werden überall dort benötigt, wo man nicht einen Haufen sich wiederholenden Code schreiben will, egal ob es sich um OOP oder Nicht-ODOP handelt.
In der OOP wurden zu diesem Zweck die Schnittstellen erfunden.
Die Schnittstellen sind ein wenig anders. Wenn ich möchte, dass derselbe Code dieselbe Aufgabe mit unterschiedlichen Typen je nach Parameterklasse erfüllt (ohne zusätzliche Klassen zu deklarieren), helfen Schnittstellen nicht weiter.
Die Schnittstellen sind ein wenig anders. Wenn ich möchte, dass derselbe Code dieselbe Aufgabe mit unterschiedlichen Typen je nach Parameterklasse erfüllt (ohne zusätzliche Klassen zu deklarieren), hilft die Schnittstelle nicht weiter.
Wenn die Parameter von unterschiedlichem Typ sind, dann macht es Sinn, mehrere überladene Methoden mit entsprechenden Typen zu machen. Man muss sie dann immer noch irgendwie in der Funktion trennen. Es ist also besser, sie in separate Funktionen aufzuteilen, als ein Durcheinander zu schaffen, das auch noch einen unpersönlichen Typ annimmt, d.h. man kann aus Versehen irgendetwas darin übergeben und bekommt einen Kompilierungsfehler innerhalb der Bibliothek, was nicht gut ist. Und vielleicht sogar nicht, was doppelt schlecht ist).
Kurz gesagt, in vollwertiger OOP sind Template-Funktionen eine Krücke (mit wenigen Ausnahmen)
Kurz gesagt, Template-Funktionen sind eine Krücke in der vollwertigen OOP.
Hier sind wir also.
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Merkmale der Sprache mql5, Tipps und Tricks
Alexey Navoykov, 2019.01.25 10:11
Nun, so habe ich das Gespräch hier begonnen. Ich hatte auch vor, alle statischen Werte durch globale Werte zu ersetzen (obwohl das natürlich eine grausame Sache ist). Aber wie oben gezeigt, funktioniert das nicht mit Vorlagen und Makros. Und die benutze ich alle häufig. Deshalb habe ich meine eigene Implementierung gemacht, die allerdings nicht alle Probleme löst. Dynamische Arrays können immer noch nicht initialisiert werden, ebenso wenig wie die konstanten Typen. Deshalb müssen sie definitiv globalisiert werden.