Warum gibt es so wenige Experten in der MQL5-Datenbank? - Seite 9
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
MyStruct' - Forward-Deklaration wird nicht unterstützt
Das war's. Wie kann man zyklische Abhängigkeiten in der Architektur beseitigen?
Sagen Sie mir nicht, dass sie in einer normalen Architektur nicht existieren können. Die einzige (Krücke) Weg ist, um die Architektur durch das Hinzufügen einer Reihe von unnötigen Basisklassen, die in einen echten Schmerz in den Arsch wegen des Fehlens der Mehrfachvererbung, die Sie abgelehnt, wie ich verstehe, nicht zu stören Umsetzung rautenförmigen Abhängigkeiten.
Aber Sie hätten die Erklärung auch einfach implementieren können...
Mal sehen, ob "unvoreingenommene Neulinge" in der Lage sind, "etwas wirklich Grundlegendes" in MQL5 zu schreiben, im Gegensatz zu "professionellen Systemprogrammierern".
Wo habe ich geschrieben, dass sie das nicht können, meine Liebe? Ja, das können sie, aber es wird etwas Rohes und Schweres sein.
Das war's. Wie kann man zyklische Abhängigkeiten in der Architektur beseitigen?
Wegen des Sicherheitssystems in komplexen Anwendungsfällen lassen wir noch keine Vorwärtsbeschreibungen zu.
Wir haben eine Sprache mit sehr strengen Kontrollen sowohl bei der Erstellung als auch zur Laufzeit. Wir können es uns nicht leisten, dass der Code aufgrund lockerer Kontrollen möglicherweise undicht wird. Der springende Punkt ist, dass diese Beschreibungen in völlig unterschiedlichen Bibliotheken stehen könnten, und es gibt noch keine strikte Möglichkeit, die Verwendung in solchen Fällen zu kontrollieren. Grob gesagt wäre es möglich, einen Angriff durchzuführen, indem man eine linkshändige Klasse mit anderen Methoden einklemmt (was derzeit nicht möglich ist).
Es gibt bereits eine Lösung für das Problem der Vorwärtsdeklaration von externen und zyklischen Abhängigkeiten, aber wir werden sie nach dem Start des 64-Bit-Terminals (Compiler, Terminal, Editor und Tester) implementieren. Wir haben heute bereits ein öffentliches 32/64-Bit-Build vorbereitet - wir werden es diese Woche veröffentlichen.
Solange man nicht anfängt, einen Managed Code Compiler mit direkter Sicherheit für das Terminal/die Ausführungsumgebung zu schreiben (C#/Java hat damit nichts zu tun, weil es nicht sicher für die Umgebung ist), ist es schwierig, die Gründe für das Handeln einiger Entwickler zu verstehen.
Mal sehen, ob "unvoreingenommene Neulinge" trotz "professioneller Systemprogrammierer" etwas "wirklich Grundlegendes" in MQL5 schreiben können.
TheXpert:
Wo habe ich geschrieben, dass sie das nicht können, meine Liebe? Ja, das können sie, aber es wird etwas Rohes und Hartes sein.
Das war's. Wie kann man zyklische Abhängigkeiten in der Architektur beseitigen?
Sagen Sie mir nicht, dass sie in einer normalen Architektur nicht existieren können. Die einzige (Krücke) Weg ist, um die Architektur durch das Hinzufügen einer Reihe von unnötigen Basisklassen, die in einen echten Schmerz in den Arsch wegen des Fehlens der Mehrfachvererbung, die Sie abgelehnt, wie ich verstehe, nicht zu stören Umsetzung rautenförmigen Abhängigkeiten.
Aber Sie hätten die Erklärung auch einfach implementieren können...
Wo habe ich geschrieben, dass sie das nicht können, meine Liebe? Ja, das können sie, aber es wird eine chaotische, schwere Sache sein.
Bei allem Respekt möchte ich anmerken, dass es nach Forum 5 zu urteilen, die Experten sind, die am meisten murren und meckern. Während gewöhnliche Amateure heulen und kreieren... Sie sind ein Experte, also werden Sie Ihrem Niveau gerecht. Entschuldigung, wenn überhaupt.
Das liegt daran, dass alles relativ ist,
Wer noch nie hinter dem Steuer eines japanischen Rechtslenkers gesessen hat, kann nicht verstehen, wie es möglich ist, das Getriebe mit der linken Hand zu schalten.
Einem Anfänger ist das egal, er weiß nicht, wie er sie nach rechts oder links verschieben kann.
Das liegt daran, dass alles relativ ist,
Wer noch nie hinter dem Steuer eines japanischen Rechtslenkers gesessen hat, kann nicht verstehen, wie es möglich ist, das Getriebe mit der linken Hand zu schalten.
und einem Anfänger ist das egal, er kann es weder mit der rechten noch mit der linken Hand schieben.
Na bitte, Sie haben alles verpfuscht. :)
Jemand, der es gewohnt ist, ein ausländisches Auto mit Automatik zu fahren, kann sich nicht in einem Shakha mit einem kaputten Getriebe bewegen. Aber derjenige, der "klassisch" gefahren ist, wird jedem Profi in "japanisch" einen Vorsprung verschaffen, wenn er "japanisch" fahren will. Ich bin nur philosophisch, ich habe gute Laune... Beachten Sie, dass ich nicht "Anfänger", sondern "Amateure" gesagt habe.
Na bitte, Sie haben alles verpfuscht. :)
Wer es gewohnt ist, ein ausländisches Auto mit Automatik zu fahren, kann sich nicht in einem Shakha mit einem kaputten Getriebe bewegen. Aber derjenige, der ein "klassisches" Auto fährt, wird jedem Profi in einem "japanischen" Auto einen Vorsprung geben, wenn er ein "japanisches" Auto fährt. Ich bin nur philosophisch, ich bin in guter Stimmung... Beachten Sie, dass ich nicht "Anfänger", sondern "Amateure" gesagt habe.
Es gibt bereits eine Lösung für das Problem der Vorwärtsdeklaration von externen und zyklischen Abhängigkeiten, aber wir werden sie nach der Einführung des 64-Bit-Terminals (Compiler, Terminal, Editor und Tester) implementieren. Wir haben heute bereits ein öffentliches 32/64-Bit-Build vorbereitet - wir werden es diese Woche veröffentlichen.
Solange man nicht anfängt, selbst einen Managed Code Compiler zu schreiben, bei dem die Sicherheit der Terminal-/Ausführungsumgebung im Vordergrund steht (C#/Java hat damit nichts zu tun, weil es für die Umgebung nicht sicher ist), ist es schwierig, die Gründe für bestimmte Handlungen der Entwickler zu verstehen.
Hier ist auch die Lösung für die Objektkonstrukteure. Die Gründe für die Unbrauchbarmachung sind unklar.
Sie nehmen keine Parameter an. Sollten wir jetzt Parameter emulieren und dazu globale Variablen verwenden?
Es gibt keinen Mechanismus, um zu melden, dass ein Objekt nicht erstellt wurde, weil beim Erstellen (Initialisieren) eines der Unterobjekte ein nicht behebbarer Fehler aufgetreten ist. Man kann allen Klassen, die in Unterobjekten verwendet werden, eine Initialisierungsfunktion hinzufügen und die Initialisierungsfunktionen der Unterobjekte von der entsprechenden Funktion der Klasse des Objekts selbst aufrufen, was die Möglichkeit bietet, einen Fehlercode zurückzugeben. Aber erstens sollte man eine solche Funktion explizit direkt nach der Erstellung des Objekts und nach der Ausführung seines "Unter"-Konstruktors aufrufen (sowie die Deinitialisierungsfunktion vor der Zerstörung des Objekts durch den Destruktor), und zweitens könnte man beim Ändern der Hauptklasse, z. B. beim Hinzufügen eines Unterobjekts, leicht vergessen, den Aufruf der Initialisierungsfunktion des hinzugefügten Unterobjekts von der Initialisierungsfunktion der Hauptklasse aus einzuschließen und auch an der richtigen Stelle, um die richtige Reihenfolge zu gewährleisten (dasselbe gilt für die Deinitialisierungsfunktion). Schließlich schreibt praktisch niemand ein ganzes Werk von Grund auf. Das Ergebnis ist ein halb handgeschriebener und unsicherer Code.
Und die vor mehr als einem Monat als solche deklarierte Veröffentlichung enthielt keine so wichtige Lösung...
Du schürst eine Menge Unbehagen, indem du alles durcheinander bringst und dir Probleme ausdenkst, die nicht einmal dich betreffen. Wenn Sie so viel Angst vor dem Schreiben haben, dann geben Sie es auf.
Du weißt, was einen schlechten Tänzer behindert.
Bei allem Respekt vor Ihnen möchte ich anmerken, dass es die Experten sind, die am meisten meckern und schimpfen, wenn man das fünfte Forum betrachtet.
Es gibt also eine Menge zu meckern. Schon bald nach der Veröffentlichung der ersten öffentlichen Beta-Version begann ich, ein Handelssystem zu schreiben. Fast sofort vermisste ich normale Konstruktoren, und dann gab ich überhaupt auf, weil es unmöglich war, einen Zeiger zu erhalten, ohne ihn explizit mit dem new-Operator zu erzeugen. Schon damals schlug ich die Möglichkeit des Imports von Klassen vor, als logische Ergänzung angesichts der zunehmenden Komplexität von Programmen und ihrer Struktur (Header- und Bibliotheks- oder Objektdateien - in einigen nur die erforderlichen Deklarationen, in anderen die Implementierung).
Importklassen und Forward-Deklarationen lösen das Problem der Codeplatzierung vollständig.
Ein Kopierkonstruktor vereinfacht das Problem der Konstruktoren.
Das Problem, das mich zum Aufhören veranlasst hat, ist gelöst. Es gibt jetzt ein GetPointer(this)-Konstrukt. Alles andere ist (bis jetzt) in der Sprache lösbar, aber es ruiniert mein Leben.
Sie sind der Experte, seien Sie Ihrem Niveau angemessen, denn die Wissenden suchen nach Möglichkeiten und die Unwissenden nach Gründen... Entschuldigung, wenn überhaupt.
Also schreibe ich weiter. Das Reden hier beeinträchtigt nicht das Schreiben von Code. Dafür brauchen Sie sich nicht zu entschuldigen - ich bin zu weit gegangen.