Wird OOP in MQL5 gefragt sein? - Seite 3

Neuer Kommentar
 

Wenigstens wird das Erlernen von MQL4 keine Zeitverschwendung sein. Wenn Sie nur Standardindikatoren verwendet haben, ist die Umstellung meines Wissens nach nicht sehr schwierig.

Ich denke, der durchschnittliche semiprofessionelle Programmierer wird OOP in MQL5 nicht brauchen.

Wenn ich den Eindruck habe, dass die Geschwindigkeit in allen Aspekten höher sein wird, würde ich lieber nicht auf solche Indikatoren achten, die große Probleme lösen können. Ich wiederhole: Ich bin kein Profi.

Obwohl, vielleicht werden Enthusiasten jetzt MQL5 verwenden, um die Entstehung von Leben aus der Primärbrühe zu simulieren? ;)

P/S Vergessen. Funktionen zur Ereignisbehandlung. Gud.

 
Es wird einen Schutz geben - die EX5-Bibliothek liefert eine Schnittstelle (eine Klasse mit virtuellen Funktionen). Im Falle einer "unkoordinierten" Verwendung mit mir wird eine Stub-Schnittstelle zurückgegeben (mit nicht sehr offensichtlichen Berechnungsfehlern).
 
mql_coder >> :
... Bibliothek gibt eine Schnittstelle (eine Klasse mit virtuellen Funktionen) zurück. Im Falle einer "unkoordinierten" Verwendung mit mir wird eine Stub-Schnittstelle (mit nicht sehr offensichtlichen Berechnungsfehlern) zurückgegeben.

Können Sie es ohne Fluchen tun? Manchmal kommen Frauen hier ins Forum.

 
mql_coder >> :
Es wird einen Schutz geben - die EX5-Bibliothek liefert eine Schnittstelle (eine Klasse mit virtuellen Funktionen). Im Falle einer "unkoordinierten" Verwendung bei mir wird ein Schnittstellen-Stub (mit nicht sehr offensichtlichen Berechnungsfehlern) zurückgegeben.

Wenn es sich lohnt, werden sie es knacken, und die Schnittstelle mit sauberen Humanoiden wird nicht helfen :)

Daher ist der Schutz derselbe wie anderswo - kein physischer Zugang zum Code, plus eine Verzögerung, die für bestimmte TS mit Handelsüberprüfung erforderlich ist (Aktienanleger können Echtzeit erhalten).


Nun, OOP in EAs ist eine sehr wertvolle Sache, ausgehend von Ereignissen, der Möglichkeit kompetenter Unterstützung und Feinabstimmung, etc. Natürlich verstehe ich nicht, warum C# nicht eine gute Idee war, weil das Fehlen von MQL5-Framework mit klaren Namespace-Deklarationen, sowie Nicht-Standard + unausgereifte Sprache, wird mehr Anstrengungen als ursprünglich vernünftig von allen erfordern :(

 
Avals >> :

Sie haben kein OOP mehr in ihrem Kern (obwohl absolutes OOP praktisch unbrauchbar ist). Wir hätten von Anfang an abstrakte Klassen erstellen und Vererbung und Polymorphismus nutzen sollen, um zu echten Objekten zu gelangen. Zum Beispiel, um eine abstrakte Basisklasse für benutzerdefinierte Indikatoren mit abstrakten Methoden und Eigenschaften zu erstellen. Es ist besser, einen hierarchischen Baum von Klassen aufzubauen: einen Baum für grafische Objekte, für die Arbeit mit dem Konto, für Zeitpläne und den Zugang zu Zeitreihen usw. Und die vordefinierten Prozeduren und Funktionen sollten nur für die elementaren Routinen verwendet werden, bei denen es auf Geschwindigkeit ankommt. Dann könnten die Fähigkeiten der Plattform von jeder Abstraktionsebene aus erweitert werden, was die Codegröße reduzieren und die Lesbarkeit und Verständlichkeit für andere Programmierer verbessern würde. Und in MT5 bereits implementiert ziemlich komplexe Dinge auf Prozedurenebene (in der Tat die ganze Plattform ist bereit, zu verwenden) und ich habe nicht gesehen, die Möglichkeit des Zugriffs durch Zeiger zumindest auf Deskriptoren der erstellten internen Strukturen, die sehr einschränkend ist (Beurteilung durch die Hilfe). Im Allgemeinen ist die Notwendigkeit von OOP fraglich, denn mit einer solchen Implementierung könnten wir uns auf Strukturen und dynamische Platzierung beschränken. OOP sollte von unten durch eine gut entwickelte Hierarchie von Klassen unterstützt werden.

Ja, genau das sage ich auch. Die Art und Weise, wie es gemacht wird, ist IMHO nicht sehr nützlich. Dafür ist das hier gedacht. Aber vielleicht gibt es ja noch andere Meinungen?

 
Whistles'n'Bells, auf jeden Fall. Wenn es jedoch eine Unterstützung für externe Objekte gibt, ist das eine gute Sache.
 
alexjou >> :
Whistles'n'Bells, auf jeden Fall. Wenn es jedoch eine Unterstützung für externe Objekte gibt, ist das großartig.

Ohne Namespaces ist das nicht wirklich machbar.

 
pisara >> :

Ohne Namespaces ist es nicht wirklich möglich, angemessene Unterstützung zu bieten.

Auf diesen neuesten Schnickschnack von Microsoft kann man verzichten. Aber man kann nicht auf diesen neuesten Schnickschnack wie " Schnittstellenbibliotheken " verzichten, zumindest solange wir über winnda sprechen. Eigentlich ist es schade, dass die MT-Entwickler dem Melkomsoft anscheinend eine unsterbliche Treue bis ins Grab geschworen haben und dem Rest keine Beachtung schenken. Mein Bauchgefühl sagt mir, dass es ein echtes Ärgernis sein wird, selbst den völlig sündlosen MT5 unter Linux via Wine zum Laufen zu bringen.

 
Die Prioritäten müssen hervorgehoben werden. Wie hoch ist der Anteil von Windows und wie hoch ist der Anteil von Linux? Wie hoch ist der Anteil von Wind für Marktanwendungen und wie hoch ist der Anteil von Linux für Marktanwendungen? Etc. Berechnen Sie als Nächstes die Wirtschaftlichkeit der Implementierung sowohl für Windows als auch für Linux. Vergessen Sie nicht den Kundendienst. Das Ergebnis ist bei weitem nicht zugunsten von Linux ausgefallen. Und das sind nicht nur Worte. Die Umleitung von Ressourcen beeinträchtigt die Qualität sowohl von Windows- als auch von Linux-Anwendungen. Es ist nicht sicher, dass mit der Streuung der Ressourcen, die methaquotes auf dem Markt bleiben werden. Im Moment hat die Veröffentlichung von MT5 für Windows oberste Priorität. Dieses Projekt sollte auf den Markt gebracht werden. Und wenn es die Ressourcen erlauben, sollten Sie auch über andere Betriebssysteme nachdenken. Auch die gleichzeitige Unterstützung von MT4 für drei Betriebssysteme (im Moment) erfordert große Ressourcen. Und dann ist da noch die Entwicklung von mt5. Wir sollten geduldig sein. OOP in MQL5 ist ein großer Schritt nach vorn. Außerdem gibt es viele andere Funktionen, die in mt4 nicht vorhanden waren. Das OOP wird gefordert oder nicht... Es wird... Ich werde es nicht massenhaft einsetzen... Und es gab keine solche Aufgabe - OOP in Massen zu verwenden. Selbst eine kleine Anzahl erstklassiger Anwendungen ist in der Lage, einen großen Marktanteil zu erobern. Und es besteht kein Zweifel, dass es solche Anwendungen geben wird.
 
Die Prioritäten müssen hervorgehoben werden. Wie hoch ist der Anteil von Windows und wie hoch ist der Anteil von Linux? Wie hoch ist der Anteil von Wind für Marktanwendungen und wie hoch ist der Anteil von Linux für Marktanwendungen? Etc. Berechnen Sie als Nächstes die Wirtschaftlichkeit der Implementierung sowohl für Windows als auch für Linux. Vergessen Sie nicht den Kundendienst. Das Ergebnis ist bei weitem nicht zugunsten von Linux ausgefallen. Und das sind nicht nur Worte. Die Umleitung von Ressourcen beeinträchtigt die Qualität sowohl von Windows- als auch von Linux-Anwendungen. Es ist nicht sicher, dass mit der Streuung der Ressourcen, die methaquotes auf dem Markt bleiben werden. Im Moment hat die Veröffentlichung von MT5 für Windows oberste Priorität. Dieses Projekt sollte auf den Markt gebracht werden. Und wenn es die Ressourcen erlauben, sollten Sie auch über andere Betriebssysteme nachdenken. Auch die gleichzeitige Unterstützung von MT4 für drei Betriebssysteme (im Moment) erfordert große Ressourcen. Und dann ist da noch die Entwicklung von mt5. Wir sollten geduldig sein. OOP in MQL5 ist ein großer Schritt nach vorn. Außerdem gibt es viele andere Funktionen, die in mt4 nicht vorhanden waren. Das OOP wird gefordert oder nicht... Es wird... Ich werde es nicht massenhaft einsetzen... Und es gab keine solche Aufgabe - OOP in Massen zu verwenden. Selbst eine kleine Anzahl erstklassiger Anwendungen ist in der Lage, einen großen Marktanteil zu erobern. Und es besteht kein Zweifel, dass es solche Anwendungen geben wird.
123456789
Neuer Kommentar