OOP vs. prozedurale Programmierung - Seite 24
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
1. Es gibt ein Kriterium. Das Hauptkriterium ist die Geschwindigkeit des Betriebs.
Die Sichtbarkeit des Codes ist das falsche Kriterium.
Alle wechseln dringend zu asambler..... aber schnell.... es stimmt, was schnell ist, ist die richtige Organisation des gesamten Projekts oder die Geschwindigkeit der einzelnen Funktionen
Jeder bewegt sich dringend zu asambler..... aber schnell.... Aber was schnell ist, ist die richtige Organisation des gesamten Projekts oder die Geschwindigkeit einzelner Funktionen.
Jeder bewegt sich dringend zu asambler..... aber schnell.... wirklich schnell ist die richtige Organisation des gesamten Projekts oder die Geschwindigkeit einzelner Funktionen
Nein, kodieren Sie weiter durch den ***.
Nun, da bin ich anderer Meinung.
Die Klarheit des Codes ist sehr wichtig, denn ein klarer Code ist viel einfacher zu pflegen und zu ändern.
Das stimmt - ich habe eine nackte Funktion geschrieben, und dann habe ich sie tatsächlich "verschleiert", sie unsichtbar und unverständlich gemacht. Dies war eine erzwungene Entscheidung. In diesem Fall war es mir wichtiger, die gesamte Klasse transparent zu machen. Ich habe die Klarheit einer recht trivialen Funktion geopfert. Natürlich hätte ich den Hauptteil dieser Funktion auch in die Datei .mq5 packen können, aber ich bin der Meinung, dass die Schnittstellen nicht in zwei Dateien aufgeteilt werden sollten und vollständig in der Header-Datei .mqh beschrieben werden sollten.
Geschwindigkeit ist auch etwas, das man im Auge behalten sollte, aber ich denke nicht, dass wir nach "Geschwindigkeit um jeden Preis" streben sollten. Es muss ein angemessenes Maß an Auskömmlichkeit gegeben sein.
Wahrscheinlich gilt Punkt 3 auch für Sie
Ich programmiere schon seit langem. Seit der Veröffentlichung von MT3.
Seitdem fühle ich mich wohler, wenn ich im prozeduralen Stil auf mql4 schreibe. Ich habe keine EAs auf 1001 Zeilen. Außerdem habe ich nur einige Funktionen in Bibliotheken gespeichert.
Und in MQL5 verwende ich die Standardbibliothek. Das ist eine praktische Sache.
Allerdings sollte die Leistung optimiert werden, damit nicht immer mehr schwere Funktionen aufgerufen werden. Vor kurzem habe ich einen EA von Mql4 auf MQL5 umgestellt. Ich habe die hier vorgestellte Bibliothek verwendet. Ich habe einen halben Tag gebraucht, um alle Funktionen herauszufinden und es hat funktioniert, aber die Optimierung war sehr langsam. Ich habe den Indikator auf 2 Balken reduziert und alles begann zu fliegen.
Die Schlussfolgerung ist einfach. Jeder kann in jedem Stil schreiben. MQL ist nicht wirklich eine Sprache, die Code-Optimierung erfordert, um ein paar Millisekunden durch prozedurale Programmierung zu gewinnen. Logische Aufgaben sind wichtiger. Die Art und Weise, wie sie umgesetzt werden, hat praktisch keinen Einfluss auf die Geschwindigkeit.
...
Die Schlussfolgerung ist einfach. Jeder kann in jedem Stil schreiben. MQL ist nicht wirklich eine Sprache, die eine Optimierung des Codes erfordert, um durch prozedurale Programmierung ein paar Millisekunden zu gewinnen. Logische Aufgaben sind wichtiger. Die Art und Weise, wie sie umgesetzt werden, hat praktisch keinen Einfluss auf die Geschwindigkeit.
So leise und unaufdringlich, dass es die prozedurale Programmierung ist, die für hohe Leistung sorgt. Seit drei Tagen zeige ich Ihnen ein Problem, das nur durch OOP ohne unnötige Bremsen gelöst werden kann.
OOP ermöglicht es, Variablensätze vom Rest des Codes abzuschirmen, wodurch die Übergabe von Parametern an Methoden bei der Durchführung von Berechnungen innerhalb einer Klasse vermieden werden kann, was ein wichtiger Faktor für die Geschwindigkeit ist. Selbst wenn Sie es im prozeduralen Stil machen, müssen Sie eine riesige Anzahl von globalen Variablen erstellen, und als Ergebnis ist die Lesbarkeit des Codes unmöglich gering.
Es wurde so sanft enttäuscht, dass es die prozedurale Programmierung ist, die hohe Leistung bietet. Seit drei Tagen zeige ich hier ein Problem, das nur durch OOP ohne unnötige Bremsen gelöst werden kann.
OOP ermöglicht es, Variablensätze vom Rest des Codes abzuschirmen, wodurch die Übergabe von Parametern an Methoden bei der Durchführung von Berechnungen innerhalb einer Klasse vermieden werden kann, was ein wichtiger Faktor für die Geschwindigkeit ist. Selbst wenn Sie dies in einem prozeduralen Stil tun, müssen Sie eine riesige Anzahl von globalen Variablen erstellen, was die Lesbarkeit des Codes erheblich beeinträchtigt.
Der Vorteil des prozeduralen Stils ist vernachlässigbar, da der Code bei jedem Tick in Expert Advisors gestartet wird. Und zwischen den Ticks können Hunderte oder sogar Dutzende von Millisekunden liegen. Ich habe mich nie mit Indikatoren beschäftigt. Ich habe keinen wirklichen Nutzen von Indikatoren gefunden.
Ich denke, es wäre bequemer, große Projekte mit OOP zu schreiben. Ich selbst ziehe es vor, Strukturen zu verwenden, wenn ich etwas speichern muss.
In diesem Fall ist der Zugriff auf die Daten übersichtlicher und das Pulldown-Menü ist sehr bequem zu bedienen. Wenn Sie Strukturen durch Arrays ersetzen, entsteht oft Verwirrung und die Anzahl der Arrays wächst.
In meinem vorherigen Beitrag habe ich den Schwerpunkt speziell auf den Aufruf schwerer Funktionen gelegt. Zum Beispiel eine Art von Schleifen, die nicht bei jedem Tick aufgerufen werden müssen. Und Sie müssen das auch nicht bei jeder neuen Bar machen.
Hier lässt sich der tatsächliche Leistungszuwachs steigern.
Ja, es ist eine lustige Debatte: Bagger gegen Schaufel.
Ich denke, wenn man einen Baum pflanzen will, ist eine Schaufel besser. Aber wenn Sie ein Loch graben wollen, ist der Bagger wahrscheinlich besser.
Ja, es ist eine lustige Debatte: Bagger gegen Schaufel.
Ich denke, wenn man einen Baum pflanzen will, ist eine Schaufel besser. Aber wenn Sie ein Loch graben wollen, ist der Bagger wahrscheinlich besser.
Ja, es ist eine lustige Debatte: Bagger gegen Schaufel.
Ich denke, wenn man einen Baum pflanzen will, ist eine Schaufel besser. Aber wenn Sie ein Loch graben wollen, ist der Bagger wahrscheinlich besser.