Diskussion zum Artikel "MQL als Darstellungsmittel für graphische Schnittstellen von MQL-Programmen. Teil 1" - Seite 2
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
...
...da mql keine Delegierten hat, musste ich herausfinden, was dieses Gericht ist und womit es gegessen wird. Ich musste alle Standardklassen neu schreiben. Ich begann von Anfang an, mit CObject. Am Ende schrieb ich eine einfache Implementierung von OnTradeTransaction, OnChartEvent, OnTimer events processing mit Hilfe von "real" OOP....
.
.
Hand aufs Herz - CObject und"Standard Library" sind noch ein Erbe der 90er Jahre :-))
bis es eine ähnliche STL geben wird, die keine zusätzlichen Attribute von Instanzen und/oder das Vorhandensein von "adam" (grand class/common ancestor) erfordert, wird es erhebliche Probleme geben - der sichtbare Teil davon ist die Menge an Anwendungsprogrammcode. Sie sind verdammt groß....
Hand aufs Herz - CObject und"Standard Library" sind ein Erbe der 90er Jahre :-)
bis es eine ähnliche STL geben wird, die keine zusätzlichen Attribute von Instanzen und/oder das Vorhandensein von "adam" (grand class/common ancestor) erfordert, wird es erhebliche Probleme geben - der sichtbare Teil davon ist die Menge an Anwendungsprogrammcode. Sie sind verdammt groß....
CObject ist hier nicht der Punkt. OOP != Patterns, verwechseln Sie nicht, wo die Macht der Patterns genutzt wird und wo die Macht von OOP genutzt wird. Es gibt keine besondere Notwendigkeit für OOP, und noch weniger für Templates, wenn man Expresso schreibt, und schon gar nicht, um ein Analogon eines Delegaten mit OOP zu erstellen, während es Zeiger auf Funktionen gibt.
So traurig es auch sein mag, der Witz über den "C++-Opferclub" wird zur Realität. Es ist seltsam, dass die Leute sich selbst mit allen möglichen Spielereien überhäufen und es für cooles Coding halten. Aber in Wirklichkeit ist der moderne Programmierer zu einem Bibliotheksstopfer verkommen.CObject ist hier nicht die Hauptsache. OOP != Templates, verwechseln Sie nicht , wo die Macht der Templates genutzt wird und wo die Macht von OOP genutzt wird. Es gibt keinen besonderen Bedarf für OOP, geschweige denn für Templates, in Expresso-Writing, geschweige denn für die Erstellung eines analogen Delegaten mit OOP, während es Zeiger auf Funktionen gibt.
So traurig es auch ist, der Witz über den "C++-Opferclub" wird zur Realität. Es ist seltsam, dass die Leute sich selbst mit allen möglichen Spielereien überhäufen und es für cooles Coding halten. Aber in Wirklichkeit ist der moderne Programmierer zu einem Library Plugger verkommen."What's the power, brother?"
Library-Plugger sollten regieren. Es ist sogar richtig, wenn es die Codegröße und die Entwicklungszeit reduziert.
PS/ Bisher sind alle veröffentlichten Artikel (und ihre Entwicklungen, was noch wichtiger ist) die Antithese der Programmierung - sie steigern nicht die Effizienz.
"Was ist die Macht, Bruder?"
library_plugins sollten die Regel sein. Es ist eigentlich das Richtige zu tun, wenn es die Codegröße und Entwicklungszeit reduziert.
PS/ Bisher sind alle veröffentlichten Artikel (und ihre Entwicklungen, was noch wichtiger ist) die Antithese der Programmierung - sie steigern nicht die Effizienz.
Die Macht liegt im Wissen, und Artikel vermitteln nur Wissen und nichts anderes sollten sie vermitteln. Die Steigerung der Effizienz ist für jeden eine persönliche Angelegenheit. Die Steigerung der Effizienz der Programmierung ist sicherlich gut, aber nicht, wenn sie den Benutzer des Programms weniger komfortabel macht.
... In der Tat ist der moderne Programmierer zu einem "Library Plugger" degeneriert.
Bald wird er ganz verschwinden, da es möglich sein wird, "Objekte" (benannte Gruppen von Parametern mit vordefinierten Verknüpfungen) intuitiv und ohne höhere Bildung zu erstellen, mit Unterstützung einer "intellektuell entwickelten" IDE, die das Wesen der logischen Struktur, die aus "einem halben Wort" aufgebaut ist, "verstehen" wird. Die Umwelt wird aufwachen und die Ära der spezialisierten Programmierer und der Sprachenvielfalt wird zu Ende gehen. Jeder wird in der Lage sein, Algorithmen zu erstellen, indem er die Anweisungen für das Programm liest. Ein natürlicher Prozess, nichts worüber man sich Sorgen machen müsste..... Es ist seltsam, dass dies nicht schon früher begonnen hat, sondern dass sich stattdessen Sprachen, die ein Konzept auf unterschiedliche Weise wiederholen, immer weiter verbreitet haben.
Es wird kein XML geben. Das Ziel ist es, ohne MQL auszukommen. Das Ziel ist es, ein MVP-Level Markup-System "native" zu MQL zu machen - ohne Schnickschnack, aber funktional und erweiterbar genug für diejenigen, die es brauchen. Es wird möglich sein, nicht auf die interne Struktur einzugehen. Es ist einfach besser, eine Beschreibung des Konzepts und des Geräts zu haben, als keine zu haben.
Ich bin auch nicht verrückt nach der Standardbibliothek, aber es gibt nicht viel Auswahl, also ist sie (im Moment) der beste Kompromiss zwischen den wenigen sehr kleinen und super ausgefallenen Bibliotheken, die ohnehin große Fragen aufwerfen.
Die vermeintlichen Koryphäen der Programmierung und GUI-Erstellung, die sich mit naivem Handwerk als solche deklariert haben, sollten ihre Hattrickkünste in eigenen Threads demonstrieren.
...
Eingebildete Koryphäen der Programmierung und GUI-Erstellung, die sich auf der Basis von naivem Handwerk als solche deklarieren, sollten in eigenen Threads ihre Hattrickkünste demonstrieren.
Bingo.