Asynchrone und mehrfädige Programmierung in MQL - Seite 12
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
(Dümmstes Gerede, sorry. ))
Wie bitte, wer? Leute, die ich nicht kenne? ))) - dies ist ein Forum - Wiki zur Rettung... es ist eine Plattform, auf der jeder seine Meinung äußert/verteidigt, nicht mehr und nicht weniger - und im Zuge der Kommunikation werden technische Aspekte und/oder der Erfahrungsaustausch geklärt, wie es bei dieser Ressource der Fall ist!
ZS:
Ihrer Meinung nach, OK, Sie sind ein Entwickler von "der richtigen grafischen Funktion" - ja, sie ist notwendig!
- Aber Sie müssen in der Lage sein, entweder eine anderen Programmierern vertraute Funktionalität zu schaffen (leider lernen alle aus der gleichen Literatur und verwenden anschließend die von den IT-Giganten angebotene Funktionalität - d.h. die vertraute, verständliche und zugängliche Funktionalität)
- oder sollten Sie ein leistungsfähiges Analysepaket in einer grafischen Oberfläche anbieten, mit dem Sie Daten untersuchen/modellieren können - sind Sie dazu in der Lage? - Können Sie z. B. mit dem R-Paket konkurrieren?
;)
Für die Suche, die Entwicklung eines TS (manche brauchen nicht einmal einen TS, George z.B. kümmert sich nicht darum, was ein TS ist), reicht MT4. Worüber reden wir dann? Jeder hat seine eigenen Bedürfnisse. Der eine lebt gut in einem Kloster, der andere will die ganze Welt bereisen. Kurz gesagt, es geht in diesem Gespräch um nichts. Das ist so, als würde ich einen Künstler fragen, warum er ein Bild malen soll, wenn er einfach ein dummes Foto von der Natur machen kann. Das ist eine dumme Unterhaltung, tut mir leid. ))
Zu der gleichen Ansicht kam ich leider auch, als ich hier mit den örtlichen "Experten" sprach ((
Wenn die Entwickler die EventLoop für asynchrone Code-Schreiben, Respekt und Bewunderung, wie sie sagen, zu schaffen.
Und das Terminal wird in seinem Produktsegment führend sein und alle anderen Terminalentwickler der Welt im wahrsten Sinne des Wortes in den Schatten stellen.
Sie wissen genau, wo es Probleme gibt, die eine asynchrone Ausführung erfordern, aber aus irgendeinem Grund werden die gleichen Indikatoren immer noch in einem Thread ausgeführt.
Und es gibt die Vermutung anderer Benutzer, dass sie aus diesem Grund keine Tick-Table-Charts implementieren - sie befürchten angeblich, dass die Benutzer eine Menge Indikatoren an ein Tick-Table-Chart anhängen werden.
Und das ist nur der sichtbare Teil, so dass es nicht immer sinnvoll ist, auf lokale Experten zu hören, die leider in einem einzigen Thread feststecken, während die Welt schon längst in mehreren Threads unterteilt ist.
Wie bitte, wer? Leute, die ich nicht kenne? ))) - dies ist ein Forum - Wiki zur Rettung... es ist eine Plattform, auf der jeder seine Meinung äußert/verteidigt, nicht mehr und nicht weniger - und im Zuge der Kommunikation werden technische Aspekte und/oder der Erfahrungsaustausch geklärt, wie es bei dieser Ressource der Fall ist!
ZS:
Ihrer Meinung nach, OK, Sie sind ein Entwickler von "der richtigen grafischen Funktion" - ja, sie ist notwendig!
- Aber Sie müssen in der Lage sein, entweder eine anderen Programmierern vertraute Funktionalität zu schaffen (leider lernen alle aus der gleichen Literatur und verwenden anschließend die von den IT-Giganten angebotene Funktionalität - d.h. die vertraute, verständliche und zugängliche Funktionalität)
- oder sollten Sie ein leistungsfähiges Analysepaket in einer grafischen Oberfläche anbieten, mit dem Sie Daten untersuchen/modellieren können - sind Sie dazu in der Lage? - Können Sie z. B. mit dem R-Paket konkurrieren?
;)
Nach Gesprächen mit den hiesigen "Experten" bin ich leider zu der gleichen Auffassung gelangt ((.
Wenn die Entwickler EventLoop für asynchrones Schreiben von Code machen, dann Hut ab und Respekt, wie sie sagen.
Und das Terminal wird in seinem Produktsegment führend sein und alle anderen Terminalentwicklungen der Welt in jeder Hinsicht übertreffen.
Sie wissen genau, wo es Probleme gibt, die eine asynchrone Ausführung erfordern, aber aus irgendeinem Grund werden die gleichen Indikatoren immer noch in einem einzigen Thread ausgeführt.
Und es gibt eine Vermutung von anderen Nutzern, dass sie aus diesem Grund keine Tick-Charts einsetzen - sie haben Angst vor negativen Konsequenzen, wenn Nutzer eine Reihe von Indikatoren an das Tick-Chart anhängen.
Und das ist nur der sichtbare Teil, so dass es nicht immer sinnvoll ist, auf lokale Experten zu hören, die leider in einem einzigen Thread feststecken, während die Welt schon längst in mehreren Threads unterteilt ist.
Ich versuche, Ihre Logik zu verstehen. Ich meine, wenn ich nicht in der Lage bin, mit dem R-Paket zu konkurrieren, dann brauche ich kein Multithreading? Wo ist hier der Zusammenhang? Versuchen Sie zu beweisen, dass, wenn Sie es nicht brauchen, es auch niemand anderes braucht? Ich wiederhole: Jeder hat andere Aufgaben. Ich habe meins, Sie haben Ihres.
Die Logik ist einfach - der Endverbraucher, wenn Sie eine Nachfrage von mindestens 1-2 Nutzern pro Monat haben, meinen Respekt - Sie haben Ihre Nische gefunden!
Die Logik ist einfach - der Endverbraucher, wenn Sie eine Nachfrage von mindestens 1-2 Nutzern pro Monat haben, meinen Respekt - Sie haben Ihre Nische gefunden!
Zu der gleichen Meinung bin ich leider gekommen, und ich habe mich hier mit den örtlichen "Experten" ausgetauscht ((
Wenn die Entwickler EventLoop für asynchrones Schreiben von Code verwenden wollen, dann respektieren Sie das, was sie sagen.
Und das Terminal wird in seinem Produktsegment führend sein und alle anderen Terminalentwicklungen der Welt in jeder Hinsicht in den Schatten stellen.
Sie wissen genau, wo es Probleme gibt, die eine asynchrone Ausführung erfordern, aber aus irgendeinem Grund werden die gleichen Indikatoren immer noch in einem einzigen Thread ausgeführt.
Und es gibt eine Vermutung von anderen Nutzern, dass sie aus diesem Grund keine Tick-Charts einsetzen - sie haben Angst vor negativen Konsequenzen, wenn Nutzer eine Reihe von Indikatoren an das Tick-Chart anhängen.
Und das ist nur der sichtbare Teil, so dass es nicht immer sinnvoll ist, auf lokale Experten zu hören, die leider in einem einzigen Thread feststecken, während die Welt schon längst in mehreren Threads unterteilt ist.
"Experten"? - Sie haben nichts zu sagen, schieben Sie Ihre imho... Dies ist eine große MQL-Gemeinschaft mit Fachleuten aus verschiedenen Bereichen, leider haben Sie nichts von Ihrem Wissen gezeigt, das für die Gemeinschaft nützlich wäre, Sie können mich beschuldigen, was Sie wollen - "Sie sind der Experte! "
Was werden die Entwickler tun? - Sie können nicht einmal erklären, WARUM das notwendig ist, oder? )))
was ist der Zweck von MetaQoutes? - das Ziel, wie jedes IT-Unternehmen, Gewinn zu machen! Ich weiß nicht warum, aber MetaQoutes nimmt die Förderung seiner Dienstleistungen sehr ernst. Es wurde viel Arbeit geleistet, um den algorithmischen Handel zu popularisieren, Analysematerial bereitzustellen und eine Online-Community zu schaffen... Diese Art von Wohltätigkeit wird nur von wenigen IT-Unternehmen geleistet, in der Regel von den IT-Giganten.
Das Unternehmen gibt also seine Ressourcen für etwas aus, das in der Zukunft (ich bin mir nicht sicher) einen Gewinn bringen wird.... und dann, siehe da... ein Benutzer auftaucht, der das Konzept von zurückgebliebenem Python oder Java an MQl.... anpassen muss Findest du das nicht lustig? - Wie alt sind Sie? ))))
Wir werden es früh genug erfahren. Das wissen wir noch nicht.
Ich respektiere Sie, Beharrlichkeit ist oft der einzige Weg, seine Nische in diesem Leben zu finden! Viel Glück bei dieser harten Arbeit!
...
Wenn sie Multithreading hinzufügen, werden Sie sich dann schlechter fühlen? Sie haben bereits eine Menge Dinge zu MQL hinzugefügt, und es ist eine wirklich nützliche Sache. Aber seine Nützlichkeit kann nur derjenige verstehen, der sehr komplexe, umständliche Programme in MQL schreibt. Wenn Sie nicht verstehen, wozu das Multi-Threading dient, bedeutet das, dass Sie solche Programme nicht schreiben. Wenn Sie das tun, werden Sie verstehen. Es ist ganz einfach. ))
...
Ich respektiere, dass Beharrlichkeit oft der einzige Weg ist, um seine Nische im Leben zu finden! Viel Glück bei dieser harten Arbeit!
Ich danke Ihnen. Das Gleiche gilt für Sie!
Nach Gesprächen mit den hiesigen "Experten" bin ich leider zu der gleichen Meinung gekommen ((
Wenn die Entwickler EventLoop für asynchrones Schreiben von Code machen, dann Hut ab und Respekt, wie sie sagen.
Und das Terminal wird in seinem Produktsegment führend sein und alle anderen Terminalentwicklungen der Welt in jeder Hinsicht in den Schatten stellen.
Sie wissen genau, wo es Probleme gibt, die eine asynchrone Ausführung erfordern, aber aus irgendeinem Grund werden die gleichen Indikatoren immer noch in einem einzigen Thread ausgeführt.
Und es gibt eine Vermutung von anderen Nutzern, dass sie aus diesem Grund keine Tick-Charts einsetzen - sie haben Angst vor negativen Konsequenzen, wenn Nutzer eine Reihe von Indikatoren an das Tick-Chart anhängen.
Und das ist nur der sichtbare Teil, so dass es nicht immer sinnvoll ist, auf lokale Experten zu hören, die leider in einem einzigen Thread feststecken, während die Welt schon längst in mehreren Threads unterteilt ist.
Sie fordern eine asynchrone Abfrageausführung, führen aber Multithreading als Beispiel an... Ich habe dich ermutigt, es herauszufinden, aber du hast es nie getan.
Ich habe Ihnen hier eine Lösung für genau Ihr Problem gegeben: https://www.mql5.com/ru/forum/318593/page4#comment_12568119
Aber ich bin mir sicher, dass Sie sich nicht einmal mit dem Thema beschäftigt haben.
Mir scheint, wenn Sie eine asynchrone Warteschlange erhalten, werden Sie trotzdem nach Multithreading fragen... Versuchen Sie zumindest zu verstehen, OVERLAPPED und Ereignisse für einen Start, sind Sie nicht fragen WinAPI in Ihrem Code).
Wenn Sie Multithreading in das Terminal einführen, wird es sich schneller als die Lichtgeschwindigkeit unter den bedauernswerten Programmierern vergraben.
Programmierer suchen nach Lösungen für Probleme und verlangen nicht, dass der Rahmen geändert wird, um ihrer Unwissenheit zu entsprechen.