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
Die hier gezeigten Beispiele (Fall 1: Rückgabewert1; Fall 2: Rückgabewert2; Fall 3: Rückgabewert3... Eine geeignete Person würde alle Werte in einem Array ablegen und den gewünschten Wert nur über seinen Index abrufen. Und für die umgekehrte Aufgabe würde er/sie die binäre Suche verwenden.
Ich bin mit beiden Händen für einen schönen Code mit Arrays. Aber beim Schreiben einer schnelleren NormalizeDouble als die reguläre, habe ich einen Optimierer-Effekt gestoßen - eine schöne Lösung über const-Array war viel langsamer als eine umständliche über switch-case. Ich habe die zweite Variante belassen, weil NormalizeDouble im Tester viel verwendet wird. Ich stecke es in den Indikator und schaue nicht auf dieses Monster. Aber die Backtests laufen schneller.
Ich erinnere mich, dass es einmal einen Thread gab, in dem über Switch diskutiert wurde und die Entwickler nur über die Implementierung als binäre Suche sprachen, die natürlich viel langsamer ist als der einfache Zugriff über einen berechneten Index.Aber jetzt scheinen sie es klüger gemacht zu haben: Wenn ein Schritt konstant ist, wird der Index berechnet, andernfalls wird eine binäre Suche durchgeführt. Natürlich ist eine native Implementierung immer schneller als eine Wrapper-Implementierung.
Das hängt natürlich von Ihren Prioritäten ab. Aber imho, wenn Geschwindigkeit so wichtig ist, dass man bereit ist, Krücken zu erfinden, dann sollte man auch OOP und MQL aufgeben ;) Obwohl ich sicher bin, dass der Geschwindigkeitsunterschied bei richtiger Codierung nicht so signifikant ist. Bei Testmessungen lässt man eine Funktion einfach millionenfach in einer Schleife hin und her springen. Und in echtem Code verwenden Sie sie rationeller, nicht wahr?
Ich erinnere mich, dass es einmal einen Thread gab, in dem über Switch diskutiert wurde und die Entwickler nur über die Implementierung als binäre Suche sprachen, die natürlich viel langsamer ist als der einfache Zugriff über einen berechneten Index.Aber jetzt scheinen sie es klüger gemacht zu haben: wenn der Schritt konstant ist, dann wird der Index berechnet, ansonsten binäre Suche. Natürlich ist die native Implementierung immer schneller als die Wrapper-Implementierung.
Der Compiler, wenn er nicht dumm ist, müsste das const-array und den einzigen Typverweis darauf durch den Index in switch-Code umwandeln.
Natürlich müssen Sie das je nach Ihren Prioritäten tun. Aber imho, wenn Geschwindigkeit so wichtig ist, dass Sie bereit sind, Krücken zu erfinden, dann sollten Sie OOP und MQL im Allgemeinen aufgeben ;) Obwohl ich sicher bin, dass bei korrekter Codierung der Geschwindigkeitsunterschied nicht so erheblich sein wird. Bei Testmessungen lassen Sie einfach eine Funktion Millionen Mal durch eine Schleife laufen. Und in echtem Code verwenden Sie es rationaler, nicht wahr?
Der Compiler, wenn er nicht dumm ist, wäre gezwungen gewesen, das const-Array und den einzigen Typverweis darauf per Index in Switch-Code zu verwandeln.
Das Array ist also nur eine Konstante? Wie steht es mit der Statik? Es ist eine einfache Operation: Vergleichen Sie den Indexwert mit der Array-/Enum-Größe, und wenn er kleiner ist, ermitteln Sie die Adresse des gewünschten Elements als Array-Adresse + Index, und lesen Sie dann den Wert von dort. Ich dachte, so ein Blödsinn muss gleich kompiliert werden.
Das Array ist also nur eine Konstante? Wie steht es mit der Statik? Es ist eine einfache Operation: Vergleichen Sie den Indexwert mit der Array-/Enum-Größe, und wenn er kleiner ist, ermitteln Sie die Adresse des gewünschten Elements als Array-Adresse + Index, und lesen Sie dann den Wert von dort. Ich dachte, so ein Blödsinn muss auf die gleiche Weise kompiliert werden.
Ich weiß nicht mehr genau, ob Sie statische Arrays mit const-Methoden erstellen können - mit Sicherheit nicht. Ich habe prinzipiell Konstanten und keine Statik gemacht. Verlassen Sie sich auf die Intelligenz des Compilers. Nach der Kompilierung sollte in den Eingeweiden kein Hinweis auf ein Array mehr zu finden sein. Eine statik ist eine viel kompliziertere Struktur als const. Deshalb war ich sicher, dass der Compiler mit der statik nicht zurechtkommen würde. Aber ich werde es versuchen müssen.
Ich weiß nicht mehr genau, ob statische Arrays konstant gemacht werden können. Im Prinzip habe ich Konstanten gemacht, keine Statik. Verlassen Sie sich auf die Intelligenz des Compilers. Nach der Kompilierung sollte in den Eingeweiden kein Hinweis auf ein Array mehr zu finden sein. Eine statik ist eine viel kompliziertere Struktur als const, so dass ich sicher war, dass der Compiler mit der statik nicht zurechtkommen würde. Aber ich werde es versuchen müssen.
Oh, das erklärt es. Sie sollten sich nicht auf die übermäßige Intelligenz des Compilers verlassen, dass er eine schlecht konzipierte Lösung für Sie weiter optimiert. Wenn Sie selbst zu faul sind, es richtig zu machen, und sagen, dass "Statik viel komplizierter ist" (obwohl ich nicht verstehe, was daran kompliziert sein soll), warum beschuldigen Sie dann den Compiler?
Oh, das erklärt es. Sie sollten sich nicht auf die übermäßige Intelligenz des Compilers verlassen, denn er wird eine schlecht konzipierte Lösung für Sie optimieren. Wenn Sie selbst zu faul sind, es richtig zu machen, und sagen: "Statik ist viel komplizierter" (obwohl ich nicht verstehe, was daran kompliziert ist), warum beschuldigen Sie dann den Compiler?
Gern geschehen. Das wird mir eine Lehre für die Zukunft sein, dass ich 7 Mal nachdenken sollte, bevor ich herumlaufe und Krücken erfinde).
Es stellt sich nun heraus, dass ich den Schalter bzw. seine Entwickler zu früh gelobt habe, so dass dort alles nur durch binäre Suche implementiert ist, auch wenn die Aufzählung mit Vielfachen geht. Nicht gut.
Gern geschehen. Es wird eine Lehre für die Zukunft sein, 7 Mal nachzudenken, bevor man losrennt und Krücken erfindet).