Características del lenguaje mql5, sutilezas y técnicas - página 163
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
no me habría dado cuenta. Aunque no excluyo que en algunos casos (cuando se trabaja con Unicode) esto sea posible. En Java, por ejemplo, el tipo char es de 2 bytes.
Intenté parsear los datos de crypto-exchange en dos variantes: a través de esta librería JSON y a través del trabajo con char array.
La diferencia resultó ser 700(!!) veces por velocidad. Me sorprendió. Quizás esté lejos de ser la mejor implementación de JSON.
carácter es 16LE y las cadenas son obviamente de pascal . Por cierto y arrays de Fortran
no me habría dado cuenta. Aunque no excluyo que en algunos casos (cuando se trabaja con Unicode) esto sea posible. En Java, por ejemplo, el tipo char es de 2 bytes.
Intenté parsear los datos de crypto-exchange en dos variantes: a través de esta librería JSON y a través del trabajo con char array.
La diferencia resultó ser 700(!!) veces por velocidad. Me sorprendió. Quizás esté lejos de ser la mejor implementación de JSON.
Al pasar la cadena mql a la dll, en el lado de la dll, el tipo de cadena mql se toma como wchar_t*.
Y el desajuste de tamaño de tipo no sólo se da en Java, depende del tipo de arquitectura, no recuerdo cuál, o del sistema operativo, o del hierro.
¿700 veces? Vaya, estaba dejando de lado esta librería para el parseo de JSON, ¿no vale la pena?
¿Y es mejor traducirStringToCharArray y analizar el array en bucle?
¿700 veces? Vaya, acabo de dejar de lado esta biblioteca para el análisis sintáctico de JSON, así que no vale la pena?
¿Y es mejor traducirStringToCharArray y analizar el array en bucle?
Creo que sí. Aunque siempre hay que comprobarlo. Hay que tomar medidas. No descarto que las funciones de cadena no estuvieran escritas de la mejor manera, y ahora se han arreglado.
Tomé estas medidas hace más de un año.
Por supuesto, el código será más grande cuando se trabaje con arrays de caracteres, pero las posibilidades son más flexibles.
Y lo más probable es que bajo mql string haya short[] o wchar_t[] o wchar_t*.
Al fin y al cabo, las cadenas mql están en Unicode, mientras que utf tiene 2 bytes.
Y StringToCharArray convierte de short[] a char[].
unicode != utf && utf != 2 bytes (utf no es lo mismo que utf) && MSVC no es un estándar
El punto de wchar_t es encajar cualquier carácter soportado en un solo wchar_t (bueno, sobre smallsoft a su manera), y los flujos de entrada y salida se convierten a/desde la codificación local por sí mismos. No hay garantías de tamaño/codificación. Cuando acepte wchar_t en la dll, piense si es correcto. A menos que, por supuesto, sea interesante mirar más allá de la caja de arena hacia el mundo de los adultos.
unicode != utf && utf != 2 bytes (utf utf'y es diferente) && MSVC no es una referencia
El punto de wchar_t es encajar cualquier carácter soportado en un solo wchar_t (bueno, sobre smallsoft a su manera), y los flujos de entrada y salida se convierten a/desde la codificación local por sí mismos. No hay garantías de tamaño/codificación. Cuando acepte wchar_t en la dll, piense si es correcto. A menos, claro, que sea interesante mirar más allá de la caja de arena hacia el mundo de los adultos.
Sí, sé que Unicode y UTF son codificaciones diferentes, y se supone que son diferentes.
Sólo quería escribir y abreviar la palabra Unicode, así que creo que no lo hice bien.
Aunque la referencia de Unicode dice que el estándar incluye caracteres de casi todas las lenguas escritas del mundo.
La norma consta de dos partes principales: el juego de caracteres universal (UCS) y el formato de transformación Unicode (UTF).
Como Unicode ya contiene una codificación UTF, lo puse así para acortar la ortografía de la palabra.
No sé si wchar_t* es correcto o no.
Usé lo que está en los ejemplos de Renat, del artículo cómo escribir dll.
Las cadenas de mql5 están en Unicode, que contiene UTF, por lo que creo que es lógico utilizar wchar_t* en el ejemplo del artículo.
Para acomodar cualquier carácter soportado en un wchar_t.
Sobre las garantías de tamaño/codificación, ni siquiera lo sabía, ¿quizás usar Cish short* para la pureza entonces?
Si el IDE de MSVC lo soporta correctamente, por supuesto.
Porque la verdad habitual será tragada por el entorno y le dará la VERDAD.
UTF-8 y UTF-16 tienen la profundidad de bits adecuada.
En UTF-8 las páginas de idiomas se cambian por códigos especiales.
UTF-16 incluye toda la variedad de caracteres al mismo tiempo.
UTF-8 y UTF-16 tienen la profundidad de bits adecuada.
En UTF-8 las páginas de idiomas se cambian por códigos especiales.
UTF-16 incluye toda la variedad de caracteres al mismo tiempo.
Bueno, según tengo entendido por lo que escribe mucha gente en el foro, las cadenas mql5 están sólo en UTF-16
Y en la documentación de mql escriben:
Una cadena de texto es una secuencia de caracteres en formato Unicode con un cero al final.
Debido a esto, es difícil entender qué codificación es realmente la cadena mql5.
Y si Unicode ya contiene todas las familias de UTF, entonces por qué usar la palabra UTF, e introducir confusión.
Unicode es todo, simple y llanamente.
¿O deberíamos decirlo así?
¿Unicode con una tasa de bits de UTF-16?
En realidad, alguien de los desarrolladores escribió antes que
El tipo de cadena mql consta de dos partes, el búfer de 8 bytes y el puntero de 4 bytes, lo que resulta en 12 bytes.
Sé que Unicode y UTF son codificaciones diferentes.
Por si acaso, quería escribir y abreviar la palabra unicode, probablemente no haya tenido suerte.
Aunque la referencia de Unicode dice que el estándar incluye caracteres de casi todas las lenguas escritas del mundo.
La norma consta de dos partes principales: el juego de caracteres universal (UCS) y el formato de transformación Unicode (UTF).
Como Unicode ya contiene una codificación UTF, lo puse así para hacer la palabra más corta.
No sé si wchar_t* es correcto o no.
Usé lo que está en los ejemplos de Renat, del artículo cómo escribir dll.
Las cadenas de mql5 están en Unicode, que contiene UTF, por lo tanto creo que es lógico utilizar wchar_t * en el ejemplo del artículo.
Para acomodar cualquier carácter soportado en un wchar_t.
Estás confundido. Unicode es una tabla de caracteres con códigos, solía caber en 0-65535(2 bytes), luego creció. Y gastar 4 bytes por carácter es gordo. Ahí es donde entra en juego utf, una codificación de longitud variable (por ejemplo, utf-8 codifica los caracteres ASCII con un byte). Por lo tanto, el Unicode (tabla) no contiene ningún utf.
Sobre las garantías de tamaño/codificación, ni siquiera lo sabía, probablemente use Cish short* para la pureza entonces ?
Si el IDE de MSVC lo soporta correctamente, por supuesto.
Porque la verdad habitual será tragada por el entorno y le dará la VERDAD.
El estándar incluye lostipos char16_t, char32_t, de tamaño fijo. Wchar_t tiene un significado diferente.
Por lo que he entendido de lo que escribe mucha gente en este foro, las cadenas mql5 están en UTF-16.
Y en la documentación de mql escriben:
Una cadena de texto es una secuencia de caracteres en formato Unicode con un cero al final.
Debido a esto, es difícil entender qué codificación es realmente la cadena mql5.
Y si Unicode ya contiene todas las familias de UTF, entonces por qué usar la palabra UTF, e introducir confusión.
Unicode es todo, simple y llanamente.
¿O debería decirse así?
¿Unicode con tasa de bits UTF-16?
Eso no es todo.
Como el cirílico ANSI = CP1251, entonces
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
¿Confusión? No, no lo he oído.
UTF-8 y UTF-16 tienen la profundidad de bits adecuada.
En UTF-8 las páginas de idiomas se cambian por códigos especiales.
UTF-16 incluye toda la variedad de caracteres al mismo tiempo.
¿Qué páginas de código, de qué estás hablando? Los "códigos especiales" definen el número de bytes para codificar un carácter porque la codificación es de longitud variable. UTF-8 puede codificar cualquier carácter Unicode al igual que UTF-16. Y utf-16 con longitud variable (pares sustitutos).