Beta-Version der MetaTrader 4 IDE mit neuem MQL4 Compiler und Editor - Seite 5
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
Einen kleinlicheren Optimierungsvorschlag kann man wohl kaum finden, aber vielleicht ist es doch an der Zeit, die Ausgabe der Marktübersichtsliste alphabetisch zu ordnen? Oder ist es der Ingenieur in mir, der sagt, dass alles parallel/rechtwinklig sein sollte... Irgendwie nicht stressig, aber auch nicht glücklich. Vielleicht könnten Sie diesen 90 % vorgefertigten Funktionen noch ein paar Zeilen hinzufügen, oder?
Frage: Wann ist der neue mt? Ich kann es kaum erwarten: .....
Worauf genau warten Sie noch? Neue Wanzen? (was bei so großen Veränderungen unvermeidlich ist). Juckt es Sie, all Ihre Codes, die nicht sofort funktionieren, neu zu schreiben und zu debuggen? Haben Sie keine Zeit zu vergeuden?
Mich persönlich hat dieses ganze Durcheinander mit den jüngsten Builds dazu gebracht, global über die Aussichten für eine solche MMS-Programmierung nachzudenken. Und es spielt keine Rolle, ob es auf 4 oder 5 ist. Die Essenz ist dieselbe. Sie schreiben Ihre Programme in einer bestimmten synthetischen Sprache, die an eine Handelsplattform gebunden ist, und schließlich werden Sie zur Geisel aller Launen und Fehler dieser Plattform-/Sprachenentwickler. Heute wollen sie MQL4 mit MQL5 kreuzen, morgen mit MQL6, usw. Und Sie haben keine Wahl, Sie sind gezwungen, Ihre Entwicklungen nach den neuen Regeln umzugestalten. Andernfalls wird alles nicht mehr funktionieren. Und so geht es weiter und weiter. Das ist alles nicht ernst gemeint.
Im Allgemeinen war dies der letzte Anstoß für mich, alle meine MQL-Programme in eine unabhängige Programmierumgebung ohne Bindung an eine bestimmte Handelsplattform zu übertragen. Und ich werde MQL nur als Bindeglied zwischen MT und meinem Programm verwenden. Und das ist wahrscheinlich der einzig richtige Weg. Es sei denn, Sie wollen Ihre Entwicklungen auf dem Markt verkaufen).
Nun, wenn Sie einfach nur gerne in MQL programmieren und einige neue Funktionen wünschen (z. B. sportliches Interesse), was hält Sie dann davon ab, in P5 zu programmieren, wo all dies bereits implementiert ist?
Worauf genau warten Sie noch? Mehr Bugs? (was bei so großen Veränderungen unvermeidlich ist). Juckt es Sie in den Fingern, all Ihre Codes neu zu schreiben und zu debuggen, die nicht auf Anhieb funktionieren? Haben Sie keine Zeit zu vergeuden?
Mich persönlich hat dieses ganze Durcheinander mit den letzten Builds dazu gebracht, global über die Aussichten für eine solche MMS-Programmierung nachzudenken. Und es spielt keine Rolle, ob es auf 4 oder 5 ist. Die Essenz ist dieselbe. Sie schreiben Ihre Programme in einer bestimmten synthetischen Sprache, die an eine Handelsplattform gebunden ist, und werden schließlich zur Geisel aller Launen und Fehler der Entwickler der Plattform/Sprache. Heute wollen sie MQL4 mit MQL5 kreuzen, morgen mit MQL6, usw. Und Sie haben keine Wahl, Sie sind gezwungen, Ihre Entwicklungen nach den neuen Regeln umzugestalten. Andernfalls wird alles nicht mehr funktionieren. Und so geht es weiter und weiter. Das ist alles nicht ernst gemeint.
Im Allgemeinen war dies der letzte Anstoß für mich, alle meine MQL-Programme in eine unabhängige Programmierumgebung ohne Bindung an eine bestimmte Handelsplattform zu übertragen. Und ich werde MQL nur als Bindeglied zwischen MT und meinem Programm verwenden. Und das ist wahrscheinlich der einzig richtige Weg. Es sei denn, Sie wollen Ihre Entwicklungen auf dem Markt verkaufen).
Und wenn Sie einfach nur gerne in MQL programmieren und einige neue Funktionen wünschen (z. B. sportliches Interesse), was hält Sie dann davon ab, in P5 zu programmieren, wo all dies bereits implementiert ist?
Ich stimme zu, wenn der Entwickler würde die Unterstützung für alte Builds zu verlassen, zumindest 500 und entfernt obligatorische Upgrade auf ein neues Build, das ich vermute, wird implementiert werden, wäre es ok, aber es ist ein weiterer unverständlicher Schritt Entwickler. Natürlich unterstütze ich die Einbeziehung von OOP, aber sie lässt sich leicht in einer DLL implementieren, und es besteht keine Notwendigkeit, mit einer neuen Version der Sprache als neuem Standard ein Feuer zu entfachen. Zum Beispiel, die gleiche C + +, sie haben mehrere bestehende Standards, aber im Allgemeinen gibt es eine gemeinsame Grundlage, die für jede Code-Implementierung funktionieren wird.
Ich habe den Verdacht, dass Sie mit Gusseisen bügeln und den Herd mit Kohle heizen ... Innovationen sind gut, nicht nur der Devisenmarkt ist sehr dynamisch und man muss immer im Trend sein, wenn man etwas erreichen will ... neue Änderungen zum Besseren, hoffentlich ....
Innovationen sind gut, nicht nur der Devisenmarkt ist sehr dynamisch und man muss immer im Trend sein, wenn man etwas erreichen will ... neue Änderungen zum Besseren, hoffentlich ....
Es ist eine Sache, selbst "im Trend" zu sein, aber es ist eine andere Sache, seine früheren Entwürfe "im Trend" liegen zu lassen. Wenn Sie nicht viele davon haben oder sie keinen Wert haben, dann ist das kein Problem. Aber viele Leute hier haben eine riesige Codebasis angesammelt, die über Jahre hinweg geschrieben und getestet wurde. Und nun werden alle vor die Tatsache gestellt, dass ein beträchtlicher Teil dieses Codes bald nicht mehr funktionieren wird. Das ist Unsinn. In solchen Fällen ist die Abwärtskompatibilität, d.h. die Unterstützung älterer Versionen der Sprache, immer vorgesehen, aber die Meta-Anführungszeichen tun dies nicht.
Es ist eine Sache, selbst "im Trend" zu sein, aber es ist eine andere Sache, seine früheren Entwürfe "im Trend" liegen zu lassen. Wenn Sie nicht viele davon haben oder sie keinen Wert haben, dann ist das kein Problem. Aber viele Leute hier haben eine riesige Codebasis angesammelt, die über Jahre hinweg geschrieben und getestet wurde. Und nun werden alle vor die Tatsache gestellt, dass ein beträchtlicher Teil dieses Codes bald nicht mehr funktionieren wird. Das ist Unsinn. In solchen Fällen wird immer eine Rückwärtskompatibilität angestrebt, d. h. die Unterstützung älterer Sprachversionen, aber die Meta-Anführungszeichen tun dies nicht.
Sind Sie sich da sicher? Ist dies ein Insider?
Es ist eine Sache, selbst "im Trend" zu sein, aber es ist eine andere Sache, seine früheren Entwürfe "im Trend" liegen zu lassen. Wenn Sie nicht viele davon haben oder sie keinen Wert haben, dann ist das kein Problem. Aber viele Leute hier haben eine riesige Codebasis angesammelt, die über Jahre hinweg geschrieben und getestet wurde. Und nun werden alle vor die Tatsache gestellt, dass ein beträchtlicher Teil dieses Codes bald nicht mehr funktionieren wird. Das ist Unsinn. In solchen Fällen wird immer eine Rückwärtskompatibilität angestrebt, d. h. die Unterstützung älterer Sprachversionen, aber die Meta-Anführungszeichen tun dies nicht.
Sind Sie sich da sicher? Ist dies ein Insider?
Die Worte eines Panikmachers. Die Metaquotes haben schon oft gesagt und werden wohl nicht müde zu wiederholen, dass es eine vollständige Kompatibilität geben wird. Hören Sie endlich auf, sich kindisch zu benehmen.
Hier habe ich sie hervorgehoben, damit niemand sagen kann, sie sei vollständig kompatibel:
Was sind die Unterschiede zur alten Version von MQL4:
Die Priorität der logischen AND/OR-Operationen hat sich geändert. Jetzt ist alles wie in klassischem C/C++
Eine verkürzte Auswertung von logischen Ausdrücken wurde eingeführt. Jetzt werden bei der Auswertung eines logischen Ausdrucks die verbleibenden Unterausdrücke nicht ausgewertet. Wie in C/C++.
Der Switch-Operator verwendet jetzt nur noch Integer-Werte. Zuvor konnte man echte verwenden.
Sie können in Variablennamen keinen Punkt verwenden. Außerdem können Sie die Zeichen '@', '$' und '?' nicht in Variablennamen verwenden.
Die Anforderungen an die Startfunktion wurden verschärft. Zuvor konnten Sie in der Startfunktion Parameter angeben. Jetzt müssen alle Einstiegspunkte init, start, deinit, OnInit, OnStart, OnTick, OnTimer usw. genau ihren Signaturen entsprechen
Aufgrund der Erweiterung der Schlüsselwortmenge können Namen wie short, long, float, const, virtual, input, delete, new, do, char nicht mehr verwendet werden.
Importierte dll-Funktionen können keine Arrays von Strings mehr als Parameter akzeptieren. Wie in MQL5
Die Unterschiede sind nicht gravierend und können im Code leicht behoben werden. Stattdessen sind viele Funktionen von MQL5, eine schnellere Ausführungsgeschwindigkeit und eine viel strengere Qualitätskontrolle verfügbar.
Ich unterstütze natürlich die Einbeziehung von OOP, aber sie ist in einer DLL implementiert und es besteht keine Notwendigkeit, eine neue Version der Sprache als neuen Standard zu schaffen.
Ich glaube nicht, dass sich in Mql4 irgendetwas geändert haben sollte. Es existiert seit vielen Jahren unverändert, alle Übel wurden beseitigt und die Nutzer haben sich daran gewöhnt. Die Hauptsache ist, dass es sich um eine sehr einfache und einzigartige Sprache mit eigenen Merkmalen handelte, die zum Beispiel einen gewissen freien Willen zuließ, wodurch viele Codezeilen eingespart werden konnten. Das einzige, was wirklich fehlte, waren Strukturen. Sie hätten sich darauf beschränken können, sie hinzuzufügen, und das wäre alles gewesen. Und MQL5 mit seiner langweiligen Strenge und seinen Beschränkungen ist nicht mehr so interessant, weil es, wie Barbarian richtig bemerkte, viel einfacher ist, in echtem C++ mit viel breiteren Möglichkeiten zu programmieren.
Kurz gesagt, die beste Lösung wäre, MQL4 so zu belassen, wie es ist, und MQL5 als separate Sprache in MT4 hinzuzufügen (nur der Funktionsumfang wird sich von MT5 unterscheiden). Der Nutzer würde selbst entscheiden, in welcher Sprache er schreibt.