Caractéristiques du langage mql5, subtilités et techniques - page 163
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
non, j'aurais remarqué. Bien que je n'exclue pas que dans certains cas (en travaillant avec Unicode) cela soit possible. En Java, par exemple, le type char est de 2 octets.
J'ai essayé d'analyser les données de la crypto-monnaie en deux variantes : via cette bibliothèque JSON et en travaillant avec un tableau de caractères.
La différence s'est avérée être 700( !!!) fois plus rapide. J'étais choqué. Peut-être était-ce loin d'être la meilleure implémentation de JSON.
Le caractère est 16LE et les chaînes de caractères sont évidemment issues de Pascal. Au fait et les tableaux de Fortran
non, j'aurais remarqué. Bien que je n'exclue pas que dans certains cas (en travaillant avec Unicode) cela soit possible. En Java, par exemple, le type char est de 2 octets.
J'ai essayé d'analyser les données de la crypto-monnaie en deux variantes : via cette bibliothèque JSON et en travaillant avec un tableau de caractères.
La différence s'est avérée être 700( !!!) fois plus rapide. J'étais choqué. Peut-être était-ce loin d'être la meilleure implémentation de JSON.
Lors du passage de la chaîne mql à la dll, du côté de la dll, le type de la chaîne mql est considéré comme wchar_t*.
Et l'inadéquation de la taille du type ne se trouve pas seulement en Java, elle dépend du type d'architecture, je ne me souviens plus lequel, ou du système d'exploitation, ou du fer.
700 fois ? Wow, je mettais justement cette bibliothèque de côté pour le parsing JSON, ça ne vaut pas le coup ?
Et c'est mieux de traduireStringToCharArray et de parser le tableau en boucle ?
700 fois ? Wow, je viens de mettre cette bibliothèque de côté pour le parsing JSON, donc ça ne vaut pas le coup ?
Et c'est mieux de traduireStringToCharArray et de parser le tableau en boucle ?
Je le pense, oui. Bien que vous devriez toujours le vérifier. Vous devez prendre des mesures. Je n'exclus pas que les fonctions de chaîne de caractères n'aient pas été écrites de la meilleure façon, et maintenant elles ont été corrigées.
J'ai pris ces mesures il y a plus d'un an.
Le code sera bien sûr plus volumineux lorsqu'on travaille avec des tableaux de caractères, mais il est plus souple.
Et très probablement sous mql string il y a short[] ou wchar_t[] ou wchar_t*.
Après tout, les chaînes mql sont en Unicode, alors que utf est de 2 octets.
Et StringToCharArray convertit les short[] en char[].
unicode != utf && utf != 2 octets (utf n'est pas identique à utf) && MSVC n'est pas une norme
Le but de wchar_t est de faire tenir tous les caractères supportés dans un seul wchar_t (enfin, à peu près à la manière de Smallsoft), et les flux d'entrée et de sortie se convertissent eux-mêmes en encodage local. Aucune garantie de taille ou de codage. Lorsque vous acceptez un wchar_t dans une dll, demandez-vous si c'est correct. À moins, bien sûr, qu'il ne soit intéressant de regarder au-delà du bac à sable, dans le monde des adultes.
unicode != utf && utf != 2 bytes (utf'y est différent) && MSVC n'est pas une référence
Le but de wchar_t est de faire tenir tous les caractères supportés dans un seul wchar_t (enfin, à peu près à la manière de Smallsoft), et les flux d'entrée et de sortie se convertissent eux-mêmes en encodage local. Aucune garantie de taille ou de codage. Lorsque vous acceptez un wchar_t dans une dll, demandez-vous si c'est correct. À moins, bien sûr, qu'il ne soit intéressant de regarder au-delà du bac à sable, dans le monde des adultes.
Oui, je sais qu'Unicode et UTF sont des codages différents, et qu'ils sont censés être différents.
Je voulais juste écrire et abréger le mot Unicode, donc je suppose que je n'ai pas bien compris.
Bien que la référence Unicode indique que la norme inclut des caractères de presque toutes les langues écrites du monde.
La norme se compose de deux parties principales : le jeu de caractères universel (UCS) et le format de transformation Unicode (UTF).
Comme Unicode contient déjà un encodage UTF, je l'ai mis de cette façon pour rendre l'orthographe du mot plus courte.
Je ne sais pas si wchar_t* est correct ou non.
J'ai utilisé ce qui est dans les exemples de Renat, de l'article comment écrire une dll.
Les chaînes mql5 sont en Unicode, qui contient UTF, donc je pense qu'il est logique d'utiliser wchar_t* dans l'exemple de l'article.
Pour accueillir tout caractère supporté dans un wchar_t.
A propos de l'absence de garanties de taille/encodage, je ne le savais même pas, peut-être utiliser Cish short* pour la pureté alors ?
S'il est correctement pris en charge par l'IDE MSVC, bien sûr.
Parce que le vrai habituel sera avalé par l'environnement et donnera le VRAI.
UTF-8 et UTF-16 ont la profondeur de bit appropriée.
En UTF-8, les pages de langue sont commutées par des codes spéciaux.
L'UTF-16 inclut toute la variété de caractères en même temps.
UTF-8 et UTF-16 ont la profondeur de bit appropriée.
En UTF-8, les pages de langue sont commutées par des codes spéciaux.
L'UTF-16 inclut toute la variété de caractères en même temps.
Eh bien, d'après ce que j'ai compris de ce que beaucoup de gens écrivent sur le forum, les chaînes mql5 sont juste en UTF-16.
Et dans la documentation mql, ils écrivent :
Une chaîne de texte est une séquence de caractères au format Unicode avec un zéro à la fin.
De ce fait, il est difficile de comprendre quel encodage est réellement la chaîne mql5.
Et si Unicode contient déjà toutes les familles d'UTF, alors pourquoi même utiliser le mot UTF, et introduire la confusion.
Unicode, c'est tout, purement et simplement.
Ou devrions-nous le dire ?
Unicode avec un débit binaire de UTF-16 ?
En fait, quelqu'un parmi les développeurs a déjà écrit que
Le type de chaîne mql se compose de deux parties, le tampon de 8 octets et le pointeur de 4 octets, ce qui donne 12 octets.
Je sais qu'Unicode et UTF sont des codages différents.
Il se trouve que j'ai voulu écrire et abréger le mot unicode, sans doute pas de chance.
Bien que la référence Unicode indique que la norme inclut les caractères de presque toutes les langues écrites du monde.
La norme se compose de deux parties principales : le jeu de caractères universel (UCS) et le format de transformation Unicode (UTF).
Étant donné qu'Unicode contient déjà un encodage UTF, je l'ai mis de cette façon pour rendre le mot plus court.
Je ne sais pas si wchar_t* est correct ou non.
Utilisé ce qui dans les exemples de Renat, de l'article comment écrire une dll.
Les chaînes mql5 sont en Unicode, qui contient UTF, donc je pense qu'il est logique d'utiliser wchar_t * dans l'exemple de l'article.
Pour accueillir tout caractère supporté dans un wchar_t.
Vous êtes confus. Unicode est une table de caractères avec des codes, elle tenait dans 0-65535(2 octets), puis elle a grandi. Et dépenser 4 octets par caractère, c'est gras. C'est là que l'utf, un codage à longueur variable, s'est révélé utile (par exemple, l'utf-8 code les caractères ASCII sur un octet). Par conséquent, l'Unicode (table) ne contient pas d'utf.
A propos de l'absence de garanties de taille/encodage, je ne le savais même pas, peut-être utiliser Cish short* pour la pureté alors ?
S'il est correctement pris en charge par l'IDE MSVC, bien sûr.
Parce que le vrai habituel sera avalé par l'environnement et donnera le VRAI.
La norme inclut lestypes char16_t, char32_t, de taille fixe. Wchar_t a une signification différente.
D'après ce que j'ai compris de ce que de nombreuses personnes ont écrit sur ce forum, les chaînes mql5 sont en UTF-16.
Et dans la documentation mql, ils écrivent :
Une chaîne de texte est une séquence de caractères au format Unicode avec un zéro à la fin.
De ce fait, il est difficile de comprendre quel encodage est réellement la chaîne mql5.
Et si Unicode contient déjà toutes les familles d'UTF, alors pourquoi même utiliser le mot UTF, et introduire la confusion.
Unicode, c'est tout, purement et simplement.
Ou devrait-on le dire de cette façon ?
Unicode avec débit binaire UTF-16 ?
Ce n'est pas tout.
Comme ANSI Cyrillic = CP1251, donc
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
Confusion ? Non, je n'ai pas entendu.
UTF-8 et UTF-16 ont la profondeur de bit appropriée.
En UTF-8, les pages de langue sont commutées par des codes spéciaux.
L'UTF-16 inclut toute la variété de caractères en même temps.
Quelles pages de code, de quoi parlez-vous ? Les "codes spéciaux" définissent le nombre d'octets pour coder un caractère car le codage est de longueur variable. UTF-8 peut encoder n'importe quel caractère Unicode aussi bien que UTF-16. Et utf-16 avec une longueur variable (paires de substituts).