Vorschläge für die MQL-Syntax - Seite 10

Neuer Kommentar
 
Es ist lustig, das alles zu lesen. Ich erinnere mich an die Schreie der alten Kameraden, als man beschloss, Klassen, "Zeiger" und Strukturen in MQL einzuführen. Sie schrieben: "Ihr habt MQL getötet! Jetzt können nur noch Profis darin schreiben...". - und anderen Unfug. Jetzt schreien sie von der anderen Seite: Lasst mich ein vollwertiges C++ haben, während das Megasystem unmöglich zu programmieren ist. Aber wer hindert Sie alle daran, das zu tun? Nehmen Sie C++ und machen Sie sich auf den Weg. MMS ist eine etwas andere Geschichte, und es ist naiv, das Warme mit dem Kalten zu verwechseln.
 

Was sagen Sie über C++... Wenn Sie C++ nicht mögen, nehmen Sie C#. Ich habe es in meinem ursprünglichen Beitrag ausdrücklich erwähnt und in weiteren Diskussionen unterstrichen. Vieles von dem, was vorgeschlagen wurde, betrifft beide Sprachen.

Es gibt also zwei Möglichkeiten: Entweder Sie sind grundsätzlich gegen den Fortschritt oder Sie meckern nur.

 
Alexey Navoykov:

...

MetaTrader ist ein gutes Terminal. Doch leider ist die große Mehrheit der Nutzer immer noch Verlierer und Glücksspieler. MQ hat große Anstrengungen unternommen, um in die Nische des intelligenten Handels vorzudringen, aber es ist ihm nicht gelungen. Zocker brauchen nur einen MT4 mit einem mehrfarbigen "TrendLaser" auf dem Chart zu "stochern". Sie scheren sich nicht um Strukturen, Klassen, Spezialitäten mit Deklination usw. Aber "ein flauschiges, dünnes Schaf" - so leben wir. Daher ist es in dieser Situation wirtschaftlich nicht machbar, Sprachfunktionen in MQL5 zu entwickeln. Aber es wäre sinnvoll, mit der Menge zu liebäugeln, z.B. Sperren im MT5 oder Open[0] statt CopyRates einzuführen.

 

Das ist schon ein bisschen seltsam. Ursprünglich wurde MQL als Anwendungssprache für das Schreiben von Handelsstrategien entwickelt. Daher enthielt es nicht alles, was C++ hat. Doch im Laufe der Zeit wurden die Aufgaben im algorithmischen Handel immer komplizierter, und die Menschen suchen und warten auf Erweiterungen der Sprache. Daher neigen sie dazu, alles, was absichtlich nicht hinzugefügt wurde, in die Liste aufzunehmen. Dadurch werden die Anzahl der Regeln und die Komplexität der Sprache zunehmen und zu einem Hindernis für sie selbst werden. Aber wenn sie bereit sind, sie zu überwinden, kann man sie nicht aufhalten.

Für mich geht es bei der Entwicklung in erster Linie darum, den richtigen und einfachsten Weg zu finden, einen Gedanken umzusetzen. Die Fähigkeiten der alten Sprache sind zwar gut genug, aber professionelle Programmierer sehnen sich nach den vielen Regeln und der unübersichtlichen Syntax. )) Nun, wenn es sie inspiriert - warum nicht?

 
Реter Konow:

Gleichzeitig werden die Anzahl der Regeln und die Komplexität der Sprache zunehmen, was für sie zu einem Hindernis wird.

Das Hinzufügen neuer Funktionen hindert sie nicht daran, die alten Funktionen zu nutzen. In der Regel ist niemand gezwungen, diese "Komplexitäten" zu nutzen.

Zwar gab es durchaus Phasen, in denen die etablierten Regeln plötzlich gnadenlos zugunsten von C++ geändert wurden, aber das war die Zeit der rasanten Entwicklung. Jetzt hat die Sprache fast alles und es bleiben nur noch kleine Änderungen übrig.

 

Übrigens habe ich persönlich das Gefühl, dass es in den letzten anderthalb Jahren nicht nur an Verbesserungen, sondern auch an Sprachfunktionen gefehlt hat. Der funktionalste und stabilste Build war 1554, datiert vom 14. März 2017.Danach gab es eine radikale Umgestaltung der Interna, und es gab problematische Builds mit vielen Bugs, von denen einige bis heute nicht behoben wurden. Allerdings wurden einige der alten Bugs behoben. Im Allgemeinen ist das Niveau der Bugs in den aktuellen Builds wahrscheinlich etwas besser. Aber zur Funktionalität...

Zum Beispiel habe ich bereits über die Streichung der Möglichkeit geschrieben, Arrays in Basistypen zu casten. Eine weitere Streichung war das Verbot, einfache Strukturen ineinander zu casten. Ja, sie wurden durch Einheiten ersetzt, aber sie decken nicht die Möglichkeiten ab, die durch den Cast gegeben waren, der die Nachteile der regulären Funktionalität kompensieren konnte. Da MQL keine Schnittstellen für Strukturen hat (ich habe bereits darüber geschrieben), war diese Lösung eine gute Alternative:

template<typename T>
struct IValueable
{ 
  double Value() const { return ((T)this).GetValue(); }
 protected:
  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

  A(double value) { _value=value; }
  
  double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print(a.Value()); }


void OnStart()
{
  A a(10);
  Func(a);
}
 
Alexey Navoykov:

Warum eine Schranke? Die Hinzufügung neuer Funktionen hindert Sie nicht daran, alte zu nutzen. In der Regel wird niemand gezwungen, diese "Komplexitäten" zu nutzen.

Natürlich gab es Zeiten, in denen bewährte Regeln plötzlich gnadenlos umgeschrieben wurden, aber das war die Zeit der rasanten Entwicklung von C++. Jetzt haben wir fast alles, und es gibt nur noch kleine Änderungen.

Ich meinte ein Hindernis für diejenigen, die die neuen Regeln und die neue Syntax selbst anwenden wollen. Sie müssen ihre Programme länger schreiben und brauchen länger, um sie zu verstehen. Wird dies ihre Programme effizienter machen? - Nicht wirklich. Werden sie in der Lage sein, eine größere Anzahl von Aufgaben zu lösen? - Nicht wirklich.

Ich habe einmal in einem Forum eine sehr einfache Lösung für eine Aufgabe vorgeschlagen, die alle mit einem Berg von Code zu lösen pflegten. Es war klein und schnell. Das hat aber nicht jedem gefallen. Es hatte nicht die Dinge, die sie mochten. Alle Arten vontemplates<typename T> undvoid Func(IValueable<A> &a)

Mir wurde angeboten, sie alle zu verwenden. Auf meine Frage "Warum?" hat mir niemand eine klare Antwort gegeben.


P.S. Die klarste Erklärung, die ich bekam, war: "Ihr Code ist hässlich". Und noch etwas: "Du verstehst die begriffliche Macht nicht". Aber ich bin ein Entwickler. Ich brauche eine schöne Lösung, keinen schönen Code.

 
Alexey Navoykov:

Ja, sie wurden durch Gewerkschaften ersetzt, aber sie decken nicht die Möglichkeiten ab, die durch die Umwandlung geschaffen wurden, die es ermöglichte, die Mängel der Standardfunktionalität auszugleichen. Da MQL keine Schnittstellen für Strukturen bietet (darüber habe ich bereits geschrieben), war diese Lösung eine gute Alternative:

Dies kompiliert.

#include <TypeToBytes.mqh>

template<typename T>
struct IValueable
{ 
  uchar Tmp;
  double Value() const { return (_C(T, this)).GetValue(); }
 protected:
//  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

//  A(double value) { _value=value; }
  void Set( double value ) { _value=value; }
  
  double GetValue() const { return _value; }
};

Aber das Ergebnis ist natürlich ein anderes.

1...345678910
Neuer Kommentar
Grund der Beschwerde: