Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 163
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
nein, das hätte ich bemerkt. Obwohl ich nicht ausschließe, dass dies in einigen Fällen (bei der Arbeit mit Unicode) möglich ist. In Java zum Beispiel ist der Typ char 2 Byte groß.
Ich habe versucht, Daten von Crypto-Exchange in zwei Varianten zu parsen: über diese JSON-Bibliothek und über die Arbeit mit Char-Array.
Der Unterschied betrug das 700(!!!)-fache der Geschwindigkeit. Ich war schockiert. Vielleicht war es bei weitem nicht die beste JSON-Implementierung.
Zeichen ist 16LE und Strings sind offensichtlich aus Pascal. Übrigens und Arrays aus Fortran
nein, das hätte ich bemerkt. Obwohl ich nicht ausschließe, dass dies in einigen Fällen (bei der Arbeit mit Unicode) möglich ist. In Java zum Beispiel ist der Typ char 2 Byte groß.
Ich habe versucht, Daten von Crypto-Exchange in zwei Varianten zu parsen: über diese JSON-Bibliothek und über die Arbeit mit Char-Array.
Der Unterschied betrug das 700(!!!)-fache der Geschwindigkeit. Ich war schockiert. Vielleicht war es bei weitem nicht die beste JSON-Implementierung.
Bei der Übergabe von mql string an dll wird auf dll-Seite der Typ mql string als wchar_t* angenommen.
Und die Fehlanpassung der Typgröße kommt nicht nur in Java vor, sondern hängt von der Art der Architektur ab, ich weiß nicht mehr welche, oder vom Betriebssystem, oder vom Eisen.
700 Mal? Wow, ich war gerade diese Bibliothek beiseite für JSON-Parsing, es ist es nicht wert?
Und es ist besser,StringToCharArray zu übersetzen und Array in der Schleife zu parsen?
700 Mal? Wow, ich habe gerade diese Bibliothek beiseite für JSON-Parsing, so ist es nicht wert?
Und es ist besser,StringToCharArray zu übersetzen und Array in der Schleife zu parsen?
Ich glaube, ja. Sie sollten es aber immer überprüfen. Sie müssen Messungen vornehmen. Ich schließe nicht aus, dass die String-Funktionen nicht optimal geschrieben waren, und jetzt wurden sie korrigiert.
Ich habe diese Messungen vor mehr als einem Jahr vorgenommen.
Der Code wird natürlich größer, wenn man mit char-Arrays arbeitet, aber die Möglichkeiten sind flexibler.
Und höchstwahrscheinlich gibt es unter mql string short[] oder wchar_t[] oder wchar_t*.
Schließlich sind mql-Strings in Unicode, während utf 2 Bytes lang ist.
Und StringToCharArray konvertiert von short[] nach char[].
unicode != utf && utf != 2 Bytes (utf ist nicht dasselbe wie utf) && MSVC ist kein Standard
Der Sinn von wchar_t ist es, jedes unterstützte Zeichen in ein einziges wchar_t zu packen (nun ja, etwa so wie smallsoft), und die Input-Output-Streams konvertieren sich selbst in/aus der Locale-Kodierung. Keine Größen-/Kodierungsgarantie. Wenn Sie wchar_t in dll akzeptieren, überlegen Sie, ob das korrekt ist. Es sei denn, es ist interessant, einen Blick über den Sandkasten hinaus in die Welt der Erwachsenen zu werfen.
unicode != utf && utf != 2 Bytes (utf utf'y ist anders) && MSVC ist keine Referenz
Der Sinn von wchar_t ist es, jedes unterstützte Zeichen in ein einziges wchar_t zu packen (nun ja, etwa so wie smallsoft), und die Input-Output-Streams konvertieren sich selbst in/aus der Locale-Kodierung. Keine Größen-/Kodierungsgarantie. Wenn Sie wchar_t in dll akzeptieren, überlegen Sie, ob das korrekt ist. Es sei denn, es ist interessant, einen Blick über den Sandkasten hinaus in die Welt der Erwachsenen zu werfen.
Ja, ich weiß, dass Unicode und UTF unterschiedliche Kodierungen sind, und sie sollen auch unterschiedlich sein.
Ich wollte nur das Wort Unicode schreiben und abkürzen, also habe ich es wohl nicht richtig gemacht.
In der Unicode-Referenz heißt es zwar, dass der Standard Zeichen aus fast allen Schriftsprachen der Welt umfasst.
Die Norm besteht aus zwei Hauptteilen: dem Universal Character Set (UCS) und dem Unicode Transformation Format (UTF).
Da Unicode bereits eine UTF-Kodierung enthält, habe ich es so geschrieben, um die Schreibweise des Wortes zu verkürzen.
Ich weiß nicht, ob wchar_t* richtig ist oder nicht.
Ich habe das verwendet, was in Renats Beispielen aus dem Artikel how to write dll steht.
mql5 Strings sind in Unicode, die UTF enthält, daher denke ich, es ist logisch, wchar_t* im Beispiel des Artikels zu verwenden.
Um jedes unterstützte Zeichen in einem wchar_t unterzubringen.
Über keine Größen-/Kodierungsgarantien, wusste nicht einmal darüber, vielleicht verwenden Cish kurz * für Reinheit dann?
Natürlich nur, wenn es von MSVC IDE korrekt unterstützt wird.
Denn gewöhnlich wird Wahres von der Umwelt geschluckt und es gibt WAHRES.
UTF-8 und UTF-16 haben die entsprechende Bittiefe.
In UTF-8 werden die Sprachseiten durch spezielle Codes umgeschaltet.
UTF-16 umfasst gleichzeitig die gesamte Vielfalt der Zeichen.
UTF-8 und UTF-16 haben die entsprechende Bittiefe.
In UTF-8 werden die Sprachseiten durch spezielle Codes umgeschaltet.
UTF-16 umfasst gleichzeitig die gesamte Vielfalt der Zeichen.
Nun, wie ich von dem, was viele Leute schreiben auf dem Forum zu verstehen, mql5 Zeichenfolgen sind nur in UTF-16
Und in der mql-Dokumentation heißt es:
Eine Textkette ist eine Folge von Zeichen im Unicode-Format mit einer Null am Ende.
Aus diesem Grund ist es schwer zu verstehen, welche Kodierung tatsächlich mql5-String ist.
Und wenn Unicode bereits alle UTF-Familien enthält, warum dann überhaupt das Wort UTF verwenden und Verwirrung stiften?
Unicode ist alles, schlicht und einfach.
Oder sollten wir das so sagen?
Unicode mit einer Bitrate von UTF-16?
Eigentlich hat jemand von den Entwicklern schon geschrieben, dass
mql string type besteht aus zwei Teilen, Puffer 8 Bytes und Zeiger 4 Bytes, was 12 Bytes ergibt.
Ich weiß, dass Unicode und UTF unterschiedliche Kodierungen sind.
Zufälligerweise wollte ich das Wort Unicode schreiben und abkürzen, wahrscheinlich kein Glück.
In der Unicode-Referenz heißt es zwar, dass der Standard Zeichen aus fast allen Schriftsprachen der Welt umfasst.
Die Norm besteht aus zwei Hauptteilen: dem Universal Character Set (UCS) und dem Unicode Transformation Format (UTF).
Da Unicode bereits eine UTF-Kodierung enthält, habe ich es so formuliert, um das Wort kürzer zu machen.
Ich weiß nicht, ob wchar_t* richtig ist oder nicht.
Ich habe das verwendet, was in Renats Beispielen aus dem Artikel how to write dll steht.
mql5 Zeichenfolgen sind in Unicode, die UTF enthält, daher denke ich, es ist logisch, wchar_t * im Beispiel des Artikels zu verwenden.
Um jedes unterstützte Zeichen in einem wchar_t unterzubringen.
Sie sind verwirrt. Unicode ist eine Tabelle von Zeichen mit Codes, die früher in die Bereiche 0-65535(2 Byte) passten, dann wuchs sie. Und 4 Bytes pro Zeichen zu verbrauchen ist fett. Da kam utf, eine Kodierung mit variabler Länge, gerade recht (utf-8 kodiert z. B. ASCII-Zeichen mit einem Byte). Daher enthält die Unicode (Tabelle) kein utf.
Über keine Größen-/Kodierungsgarantien, wusste nicht einmal darüber, vielleicht verwenden Cish kurz * für Reinheit dann?
Natürlich nur, wenn es von MSVC IDE korrekt unterstützt wird.
Denn übliche Wahrheiten werden von der Umwelt geschluckt und geben ihr WAHR.
Der Standard umfasst char16_t, char32_t, Typen mit fester Größe. Wchar_t hat eine andere Bedeutung.
Soweit ich verstanden habe, was viele Leute in diesem Forum schreiben, sind mql5-Strings in UTF-16.
Und in der mql-Dokumentation heißt es:
Eine Textkette ist eine Folge von Zeichen im Unicode-Format mit einer Null am Ende.
Aus diesem Grund ist es schwer zu verstehen, welche Kodierung tatsächlich mql5-String ist.
Und wenn Unicode bereits alle UTF-Familien enthält, warum dann überhaupt das Wort UTF verwenden und Verwirrung stiften?
Unicode ist alles, schlicht und einfach.
Oder sollte man es so sagen?
Unicode mit UTF-16-Bitrate ?
Das ist noch nicht alles.
Da ANSI Kyrillisch = CP1251, also
Unicode:
UTF-8 = CP65001, // UNIX/Linux
UTF-16LE = CP1200, // Windows
UTF-16BE = CP1251,
UTF-32LE = ?
UTF-32BE = ?
ISO10646:
UCS-2 ~ UTF-16
UCS-4 = UTF-32
Verwirrung? Nein, das haben wir nicht.
UTF-8 und UTF-16 haben die entsprechende Bittiefe.
In UTF-8 werden die Sprachseiten durch spezielle Codes umgeschaltet.
UTF-16 umfasst gleichzeitig die gesamte Vielfalt der Zeichen.
Welche Codeseiten, wovon reden Sie? Die "Spezialcodes" legen die Anzahl der Bytes fest, mit denen ein Zeichen kodiert wird, da die Kodierung eine variable Länge hat. UTF-8 kann jedes Unicode-Zeichen ebenso gut kodieren wie UTF-16. Und utf-16 mit variabler Länge (Surrogatpaare).