Interessantes Thema für viele: was ist neu in MetaTrader 4 und MQL4 - große Änderungen auf dem Weg - 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
Da wir nun den Markt berührt haben, würde ich gerne Meinungen zu einem Thema hören...
Nach der Philosophie von MQL5 sollen Indikatoren zählen und EAs handeln.
Aber Market verkauft fertige Lösungen, wie man so schön sagt, alles in einem.
Wie wäre es, den Compiler so zu verbessern, dass Indikatoren in EAs als Ressourcen gespeichert werden?
Andernfalls müssen wir den Code des Indikators in den Expert Advisor übertragen, wo er keine geeignete Umgebung hat. Auch hier macht das Schema "Indikator aus Indikator" die Übertragung des Codes auf den Expert Advisor zu einem Kinderspiel.
Ich stimme zu,
Ich denke, es wäre nützlich, eine Registerkarte für den Markt hinzuzufügen - DATEIEN, wo man Sets, Anleitungen usw. ablegen kann,
Ich denke, es wäre nützlich, eine Registerkarte - DATEIEN - hinzuzufügen, in der Sie Sets, Anweisungen usw. speichern können.
Können wir den Compiler verfeinern, um Indikatoren in EAs als Ressourcen zu speichern?
Andernfalls müssen wir einen Indikatorcode in einen Expert Advisor übertragen, wo er keine geeignete Umgebung hat. Auch hier macht das Schema "Indikator aus Indikator" das Verschieben des Codes in den Expert Advisor zu einem wahren Kinderspiel.
Siehe MetaTrader 5 Client Terminal build 730 am 24. November 2012
8. MQL5: Unterstützung für die Speicherung von Indikatoren in EX5-Ressourcen hinzugefügt. Gleichzeitig werden Indikatoren für Ressourcen nicht mit ihren eigenen Ressourcen arbeiten können.
Siehe Pressemitteilung MetaTrader 5 Client Terminal build 730 vom 24. November 2012
Das ist genau das, was ich tue. Und ich habe bereits Klassen geschrieben, die den Expert Advisor benutzerdefinierte Geschichte (anstelle der realen Geschichte vom Server) übergeben können. Aber der Expert Advisor sollte nicht Funktionen des Terminals direkt verwenden, um meine Idee vollständig zu implementieren. Sagen wir, die gleiche OrderSend(). Es sollte nur durch einen "Wrapper" funktionieren, dessen Rolle wunderbar von der Standardbibliothek übernommen werden kann. Wir schreiben abgeleitete Klassen, binden sie in den Expert Advisor ein, und voilà - er arbeitet jetzt mit historischen Daten. Wenn der Expert Advisor die Funktionen des Terminals direkt verwendet, kann er die Historie nicht nutzen.
Nun, vielleicht liegt es an meiner langen Arbeit mit der MFC-Bibliothek, mit der ich sehr zufrieden war und zu der ich viele Parallelen finde. Ich bin sicher, dass die Entwickler der Standardbibliothek auch mit der MFC gut vertraut sind.
Der Hauptvorteil der Standardbibliothek ist die gute Unterstützung der OOP-Ideologie, die es ermöglicht, dem Expert Advisor eine benutzerdefinierte Historie zu übergeben, so dass er ohne jegliche Änderungen ordnungsgemäß funktioniert.
Darf ich fragen, was Sie an der Standardbibliothek nicht mögen (abgesehen von dem offensichtlichen Nachteil - "lernfaul")?
Das ist eben kein Nachteil, ich kenne SB sehr gut, und dieses Wissen gibt mir ein Verständnis dafür, wie umständlich und ineffizient alles ist.
Anstatt eine Bestellung aufzugeben, starten Sie einen Großvater für einen Großvater und einen Großvater für eine Rübe.
Der größte Nachteil ist jedoch (laut Trade), dass es absolut keine Kontrolle der Ausführung gibt. Sie schicken einfach eine Bestellung an den Server und lassen das Gras wachsen. Aber sie verpackten Send auf 10 Arten, wie für alle Gelegenheiten, aber es wurden 100 Fälle daraus.
Was die Ideologie betrifft, so ist die Vererbung über mehr als 2 Generationen ein Fehler, denn dann gehen sowohl Verständnis als auch Flexibilität verloren.
Die meisten Klassen (da hast du recht) wurden nicht erfunden, sie wurden einfach aus der MFC übernommen, aber das ist kein Nachteil, warum sollte man das Rad neu erfinden.
Aber ich denke, der größte Nachteil ist, dass sie sich nicht darauf verlassen können).
Ich habe sowohl mit als auch ohne SB geschrieben. Ohne sie werden Sie schneller und transparenter. Es ist zu vielseitig und daher in Kurven zu träge.
In Delphi gibt es zum Beispiel das Konzept eines Projekts, das eine gemeinsame Kompilierung impliziert. Und die Einteilung von Programmen in 3 Typen ist generell etwas fragwürdig, da der Compiler theoretisch selbst bestimmen kann, was das Programm tut, aber da es so weit geht, dass Indikatoren nur mit Gewalt handeln und für EA muss man Code im Inneren implementieren, können wir nur hoffen, dass das Herz der Entwickler jemals schmelzen wird und sie es erlauben werden, Projekte zu machen).
sekundiert,
Ich denke, es wäre nützlich, eine Registerkarte DATEIEN für den Marktplatz hinzuzufügen, um z. B. Sets, Anleitungen usw. zu speichern,
Die Registerkarte "Diskussion" ermöglicht dies zwar, aber es ist trotzdem nicht dasselbe.
Siehe MetaTrader 5 Client Terminal Build 730 vom 24. November 2012
Großartig, wie konnte ich das verpassen, aaah, das sind die Bauarbeiten vor den Ferien.
Bedeutet die Kreuzung in Ihrem Beitrag, dass sie das bereits können?
Ich kenne SB sehr gut und weiß daher, wie umständlich und ineffizient alles ist.
Ich danke Ihnen für Ihre ausführliche Antwort. Ich habe keine kategorischen Einwände gegen eine Ihrer Aussagen. Nur... einige Beobachtungen...
Anstatt eine Bestellung zu schicken, Großvater für Großvater, Großvater für Rübe.
Aber genau das macht das System flexibel und ermöglicht es uns, benutzerdefinierte Verlaufsdaten und Serveremulationen an den EA zu senden. Wenn Bestellungen direkt über OrderSend() gesendet würden, müssten wir dieses "Oma für Opa, Opa für Opa" selbst schreiben... Es ist nicht klar, was besser ist...
Der größte Nachteil ist jedoch (laut Trade), dass es absolut keine Kontrolle der Durchsetzung gibt. Wenn Sie eine Bestellung an einen Server weiterleiten und sich nicht darum scheren. Aber sie verpackten Send auf 10 Arten, wie für alle Gelegenheiten, aber es wurden 100 Fälle daraus.
Ich bin hier nicht erfahren genug - ich kann nur theoretisieren. Ich analysiere selbst Rückgabecodes, aber ich habe nur sehr wenig Erfahrung. Ich stimme zu, dass es in SB selbst keine ausreichende Kontrolle der Ausführung gibt.
Was die Ideologie betrifft, so halte ich die Vererbung über mehr als 2 Generationen für einen Fehler, da man dann sowohl das Verständnis als auch die Flexibilität verliert.
Ja, eine zu tiefe Vererbung ist in der Tat sehr schädlich für das Verständnis. Aber was die Flexibilität betrifft, so kann ich dem nur schwer zustimmen. Ich habe eine Reihe von Fällen von Vererbung in der 4. und 5. Generation, und es scheint keine Probleme zu verursachen. Aber ich kann zustimmen, dass dies bei mir der Fall ist, für andere kann diese Tiefe der Vererbung ein großes Hindernis sein.
Aber der größte Nachteil ist meiner Meinung nach, dass man sich nicht darauf verlassen kann, man schreibt etwas darauf und es wird überarbeitet :)
Ja, dem kann ich nur zustimmen.
Ich habe sowohl mit als auch ohne SB geschrieben. Ich habe mit SB geschrieben, aber ohne es wurde ich schneller und transparenter. Er ist zu vielseitig und daher in Kurven ungeschickt.
Ich mochte SB wegen seiner Fähigkeit, eine TC-Vorlage zu erstellen und anschließend nur Objektklassen, die Eingaben, Wartung und Ausgaben beschreiben, damit zu verbinden. Ich fürchte, dass eine solche Ideologie ohne SB zur Schaffung der gleichen, nur eigenen SB führen würde.
Was "schneller und transparenter" betrifft, so scheint mir, dass eine solche Ideologie gut ist, wenn wir jeden TS als Ganzes behandeln lassen. Meines Erachtens ist dies jedoch ein schwerwiegender Fehler beim Algotrading. TS sollte nur als ein Satz von "Würfeln" betrachtet werden - ein Satz von Eingangsgeneratoren, Determinante des Eingangs TP-SL, Determinante des Eingangs Los, nachlaufender Regler und so weiter... Diese Ideologie ermöglicht es, sehr schnell Hunderte von verschiedenen TS-Varianten zu erhalten, von denen wir nur einige wenige "schneller und transparenter" haben.
Wenn wir z. B. fünf verschiedene TS ohne Vorlage geschrieben haben, müssen wir, um die sechste zu schreiben, alles noch einmal von vorn beginnen, wobei wir sogar Teile dieser fünf Systeme verwenden. Nachdem wir die Vorlage geschrieben haben, geben wir diese fünf Systeme nur teilweise in sie ein, und als Ergebnis haben wir bis zu fünf Eingabegeneratoren, Eingabefilter, TP-SL-Determinanten usw. Kombiniert man sie, erhält man leicht hundert TS, aus denen man die stabilsten und profitabelsten auswählen kann.
Daher ist die Schwerfälligkeit von SB meiner Meinung nach wirklich ein "Stock mit zwei Enden", und seine Anwendung oder Nichtanwendung sollte in jedem einzelnen Fall entschieden werden.
Super, wie konnte ich das verpassen, ahhhhh sind die vor-Neujahr-Builds.
Bedeutet die Durchstreichung in Ihrem Beitrag, dass sie das bereits können?
Toll, wie konnte ich das nur übersehen, das sind die Bauarbeiten vor Neujahr.
Es wurde hier besprochen: https://www.mql5.com/ru/forum/3409#comment_408123