Erstellen einer grafischen Benutzeroberfläche für MQLs im grafischen Modus. - Seite 11
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
Warum ist das immer noch der Fall?
Alle Möglichkeiten der Interoperabilität gibt es schon seit langem. Die DLL-Unterstützung im Allgemeinen wurde 2004 eingeführt.
Unsere Sprachen entwickeln sich ständig weiter und werden immer leistungsfähiger und funktionaler. Und das Ökosystem ist leistungsfähiger als alle anderen.
Gut gemacht! Und ich bin sicher, dass es nur noch besser wird! Die Abwesenheit von Starrheit ist die beste Eigenschaft eines Teams und der Erfolg von Entwicklern! ))
Gut gemacht! Und ich bin sicher, dass es nur noch besser wird! Die Abwesenheit von Starrheit ist die beste Eigenschaft eines Teams und der Erfolg von Entwicklern! ))
Unsere Partei ist unser Steuermann! Weg mit der Starrheit - her mit den Parteilinien! Komm schon!!!
Gut gemacht! Und ich bin sicher, dass es nur noch besser wird! Die Abwesenheit von Starrheit ist die beste Eigenschaft eines Teams und der Erfolg von Entwicklern! ))
Das wird so sein, vor allem, wenn wir im September die 32-Bit-Versionen einfrieren und nur noch 64-Bit-Versionen unterstützen werden.
Jetzt bereiten wir ein ernsthaftes Upgrade des Compilers mit der Übertragung einiger Systemfunktionen in MQL5-Programme vor, was den Optimierer dramatisch verbessern und den resultierenden Code von MQL5-Programmen beschleunigen wird.
Wir werden vollständige Leistungsbenchmarks zum Vergleich mit C++ zusammen mit dem Quellcode veröffentlichen, so dass jeder sie selbst überprüfen kann.
Warum ist das immer noch der Fall?
Alle Möglichkeiten der Interoperabilität gibt es schon seit langem. Die DLL-Unterstützung im Allgemeinen wurde 2004 eingeführt.
Unsere Sprachen entwickeln sich ständig weiter und werden immer leistungsfähiger und funktionaler. Und das Ökosystem ist leistungsfähiger als alle anderen.
Es ist auf einem Niveau, sorry, etwa wie Borland C++ in den späten 80er Jahren. Geben Sie uns eine voll funktionsfähige API mit Ereignissen und Spalten, die als COM-Objekt implementiert werden kann - das Terminal wäre unbezahlbar.
Warum verzeihen? Hören Sie auf zu schwärmen, bitte.
Wir haben eine leistungsstarke Anwendungssprache, die durch das von uns aufgebaute Ökosystem gezeigt hat, dass wir auf dem richtigen Weg sind. Schutz von Nutzern, Entwicklern und uns selbst.
Dies ist ein Geschäft, keine Plattform für Populisten.
Das ist ein Niveau, sorry, etwa wie Borland C++ in den späten 80er Jahren. Geben Sie mir eine voll funktionsfähige API mit Ereignissen, Coliboxen, die als COM-Objekt implementiert sind - und das Terminal wird keinen Wert haben.
Obwohl es schnell veraltet, wäre es eine gute Lösung für eine COM-Schnittstelle.
Nur passt es nicht wirklich in die reale Zeit :-(.
Warum verzeihen? Hören Sie auf zu schwärmen, bitte.
Wir haben eine Anwendungssprache, die durch das aufgebaute Ökosystem gezeigt hat, dass wir auf dem richtigen Weg sind. Schutz von Nutzern, Entwicklern und uns selbst.
Dies ist ein Geschäft, keine Plattform für Populisten.
Eine COM-Schnittstelle für das Terminal wäre eine tolle Sache, auch wenn sie schnell veraltet ist.
Aber es passt nicht wirklich in die Echtzeit :-(.
Das werden wir, vor allem wenn wir im September die 32-Bit-Versionen einfrieren und nur noch 64-Bit-Versionen der Plattform unterstützen werden.
Jetzt bereiten wir ein ernsthaftes Upgrade des Compilers vor, indem wir einige Systemfunktionen in MQL5-Programme verschieben, was den Optimierer dramatisch verbessern und den resultierenden Code von MQL5-Programmen beschleunigen wird.
Wir werden vollständige Leistungsbenchmarks zum Vergleich mit C++ zusammen mit dem Quellcode veröffentlichen, so dass jeder sie selbst überprüfen kann.
Renat, bevor Sie x32 deaktivieren, stellen Sie bitte sicher, dass Sie x64 unter Ihrem Hostnamen ausführen. Wenn Sie das nicht wollen/brauchen, sagen Sie es mir auch, damit wir Zeit haben, die Optionen zu überdenken.
Und lassen wir die weiblichen Emotionen beiseite und bleiben bei den Zahlen. Wie hoch ist die Belastung der CPU, die diesen schrecklichen Engpass bedient? Die CLR-Engine läuft ohnehin ständig in Windows, und wir sind nicht die Einzigen, die sie verwenden. In erster Linie ist es der Wind selbst, der ihn nutzt.
Das ganze .net, # Ding ist eine langsame und unbeholfene Maschine, wie kann man verwalteten und nativen Code vergleichen?
"Und die CLR-Maschine läuft sowieso ständig im Wind, wir sind nicht die einzigen, die sie benutzen. Es ist in erster Linie der Wind selbst, der ihn nutzt" - ich habe Verständnis dafür. Was den Arbeitsspeicher betrifft, so ist hier mein Speicherverbrauch durch das System (Linux):
MiB Mem : 2998.9 gesamt, 2411.2 frei, 38.9 benutzt, 548.8 Puffer/Cache
38,9 MB, unerreichbar für Windows mit seinen virtuellen Maschinen, obwohl ich keinen Swap verwende:
MiB Swap: 8192.0 gesamt, 8192.0 frei, 0.0 benutzt. 2474.6 verfügbarer Speicher
Und Sie können sagen, ohne Emotionen - in welcher Weise Formen in C # sind besser als in C++/FLTK, zum Beispiel gibt es ein Formular-Editor - FLUID, wenn auch nicht notwendig, meiner Meinung nach, ein einfaches Fenster, ein Dutzend oder zwei Dutzend Zeichenfolgen?