Gemeinsam lernen und schreiben in MQL5 - Seite 19
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
(Ja und der Antrag, leider wenig begründet und mit überzeugenden Argumenten untermauert).
PS
Es kann aber auch sein, dass ich etwas übersehen habe und die Entwickler es für angemessen halten.
Ich wiederhole: Es gab keine Anfrage an die Entwickler :) Es gab keine Anforderungen oder gar Wünsche - ganz im Sinne des Themas der Branche. Wie das Sprichwort sagt: "gesegelt, wir wissen es" :) Den Grund dafür habe ich hier erklärt:"Wenn jemand eine solche Frage vor einem halben Jahr gestellt hätte, könnten wir immer noch auf ein relativ schnelles Erscheinen der Funktion hoffen, aber es ist einfacher, auf das nächste Jahr zu warten, um eine Variable für das Datum einzuführen, die zwar nicht ganz genau sein wird, aber immerhin.
Wie immer danke ich Ihnen allen für Ihre Gedanken! Diesmal hast du mich überzeugt, dass ich Recht habe :)
stringo:
Frage. Die Beschreibung von switch(expression){...} besagt, dass "der Ausdruck des switch-Operators vom Typ Ganzzahl sein muss". Ich habe die Beschreibung dieses Operators mit Ausdrücken anderer Typen im Internet gesehen. Werden wir die Verwendung des Switch-Operators erweitern, indem wir Ausdrücke vom Typ String hinzufügen?
Nein, das wird es leider nicht. Bei String-Typen nur, wenn ... sonst wenn ... sonst .
Die Verwendung von Integer-Typen in switch beschleunigt den switch-Operator um ein Vielfaches, als wenn
Frage. Gibt es (in Analogie zu switch) einen Geschwindigkeitsvorteil im Vergleich zu if des"bedingten Operators ?:"?
Frage. Gibt es (in Analogie zu switch) einen Geschwindigkeitszuwachs im Vergleich zu if für den"bedingten Operator ?:"?
Nein. Der bedingte Operator hat im Vergleich zu if keine Beschleunigung. Es ist einfach leichter zu schreiben.
AUFTRAGSART_KAUFEN_STOPP_LIMIT
Wenn der Auftragspreis erreicht ist , wird ein schwebender Kauf-Limit-Auftrag zum StopLimit-Preis platziert .
Es scheint, dass die Verarbeitung dieses Auftrags, einschließlich des Setzens eines schwebenden Buy-Limit-Auftrags, auf der Serverseite erfolgt. Ich habe einige Fragen, auf die ich in der Referenz keine Antworten finden konnte:
1) WirdORDER_TYPE_BUY_STOP_LIMIT selbst in die Historie aufgenommen, wenn der Auftragspreis erreicht und der schwebende Buy-Limit-Auftrag erteilt wird?
2) Wird das Ticket einesORDER_TYPE_BUY_STOP_LIMIT-Auftrags an einen neuen, auf der Serverseite platzierten Auftrag vererbt?
3) Wird ein Handelsereignis generiert, wenn eine server-seitige schwebende Buy-Limit-Order platziert wird?
4) Wie (nach welcher Regel) werden einer neuen schwebenden Buy-Limit-Order auf der Serverseite die Verfallszeit, die Auftragsdauer und der Kommentar zugewiesen?
Und gibt es generell eine intelligente Möglichkeit, die Erteilung von Aufträgen auf der Serverseite schnell zu erfassen? Ist dies irgendwo erwähnt worden?
...
CopyTime(_Symbol,_Zeitraum,0,1,Alte_Zeit);
Yedelkin:
...Die Funktion Sleep() verlangsamt den Thread selbst nicht
Es verlangsamt sich zwar, aber es setzt CPU-Ressourcen für andere Threads frei.
Deshalb sollten Sie Sleep nicht in Indizes verwenden - ein Thread kann viele Indizes berechnen und Sleep in einem Thread führt dazu, dass alle anderen ebenfalls im Leerlauf sind.
________
Verdammt, ich bin zu spät :) das nächste Mal werde ich mir die Daten genauer ansehen.
Der Thread ist überhaupt nicht mit dem Kernel verbunden.
Er verlangsamt sich zwar, setzt aber CPU-Ressourcen für andere Threads frei.
Aus diesem Grund sollte Sleep nicht in Indulatoren verwendet werden - ein Thread kann eine große Anzahl von Indulatoren berechnen und Sleep in einem Thread führt dazu, dass alle anderen ebenfalls im Leerlauf sind.
________
Verdammt, ich bin zu spät:) das nächste Mal werde ich mir die Daten genauer ansehen.
Über "spät". - Das ist richtig! Der Schlüsselbegriff ist hier "Freisetzung von CPU-Ressourcen für andere Threads". Das ist genau das, was ich in der Frage zu formulieren versucht habe.
AUFTRAGSART_KAUFEN_STOPP_LIMIT
Wenn der Auftragspreis erreicht ist , wird ein schwebender Kauf-Limit-Auftrag zum StopLimit-Preis platziert .
Es scheint, dass die Verarbeitung dieses Auftrags, einschließlich des Setzens eines schwebenden Buy-Limit-Auftrags, auf der Serverseite erfolgt. Ich habe mehrere Fragen, auf die ich in den Referenzmaterialien keine Antworten gefunden habe: ...
Nach dem Mangel an Antworten auf die Frage zu urteilen, sind die Leute hier nach dem MT4 und sind noch nicht zu Stop-Limit-Aufträgen übergegangen :)
Und ohne Text zu sprechen, habe ich im Internet Materialien gefunden, die besagen, dass ein STOP LIMIT-Auftrag keinen neuen schwebenden Auftrag erzeugt, sondern sich einfach in einen Limit-Auftrag umwandelt, wenn eine bestimmte Bedingung erfüllt ist:
- einen bedingten Auftrag, der in einen Limit-Auftrag umgewandelt wird , wenn der Kontraktpreis ein bestimmtes Niveau erreicht;
- ein Auftrag zur Ausführung eines Geschäfts zu einem Preis, der schlechter ist als der aktuelle Marktpreis, aber nicht schlechter als der im Limit-Teil des Auftrags angegebene Preis. Im Gegensatz zu einer Stop-Order wird diese Order als Limit-Order aktiviert , wenn der Marktpreis den in der Order angegebenen Preis erreicht. In diesem Fall kann der Ausführungskurs eines Stop-Limit-Auftrags entweder gleich dem Auftragskurs oder besser als dieser sein;
- ein Kundenauftrag, der zu einem Limitauftrag wird , sobald der Marktpreis das festgelegte Niveau (Stoppkurs) erreicht;
usw.
Dieser Ansatz beantwortet die meisten meiner Fragen. Wenn dies jedoch der Fall ist, dann ist die Formulierung im Handbuch über die "Platzierung eines Limit-Auftrags" falsch und besonders verwirrend.