Características da linguagem mql5, subtilezas e técnicas - página 163
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
não teria reparado. Embora eu não exclua que em alguns casos (quando se trabalha com Unicode) isto seja possível. Em Java, por exemplo, o tipo char é de 2 bytes.
Tentei analisar os dados a partir da troca criptográfica em duas variantes: através desta biblioteca JSON e através do trabalho com char array.
A diferença acabou por ser de 700(!!!) vezes por velocidade. Fiquei chocado. Talvez estivesse longe de ser a melhor implementação do JSON.
O carácter é 16LE e as cordas são obviamente de pascal . A propósito, e matrizes de Fortran
não teria reparado. Embora eu não exclua que em alguns casos (quando se trabalha com Unicode) isto seja possível. Em Java, por exemplo, o tipo char é de 2 bytes.
Tentei analisar os dados a partir da troca criptográfica em duas variantes: através desta biblioteca JSON e através do trabalho com char array.
A diferença acabou por ser de 700(!!!) vezes por velocidade. Fiquei chocado. Talvez estivesse longe de ser a melhor implementação do JSON.
Ao passar mql string para dll, no lado dll, o tipo mql string é tomado como wchar_t*.
E o desajuste do tamanho do tipo não se encontra apenas em Java, depende do tipo de arquitectura, não me lembro o quê, nem do sistema operativo, nem do ferro.
700 vezes? Uau, eu só estava a pôr esta biblioteca de lado para a análise do JSON, não vale a pena?
E é melhor traduzirStringToCharArray e parse array em loop?
700 vezes? Uau, acabei de pôr esta biblioteca de lado para a análise do JSON, por isso não vale a pena?
E é melhor traduzirStringToCharArray e parse array em loop?
Penso que sim. Embora deva sempre verificá-lo. Tem de se fazer medições. Não excluo que as funções das cordas não tenham sido escritas da melhor maneira, e agora foram corrigidas.
Fiz estas medições há mais de um ano.
O código será obviamente maior quando se trabalha com matrizes de carvão, mas as possibilidades são mais flexíveis.
E o mais provável é que, sob uma corda mql, haja short[] ou wchar_t[] ou wchar_t*.
Afinal, mql strings estão em Unicode, enquanto utf é 2 bytes.
E StringToCharArray converte de short[] para char[].
unicode != utf && utf != 2 bytes (utf não é o mesmo que utf) && MSVC não é um padrão
O objectivo do wchar_t é encaixar qualquer carácter suportado num único wchar_t (bem, cerca de pequenos soft à sua maneira), e os fluxos de saída de entrada convertem-se de/para a codificação locale em si mesmos. Sem garantias de tamanho/codificação. Ao aceitar wchar_t em dll, pense se está correcto. A menos, é claro, que seja interessante olhar para além da caixa de areia para o mundo adulto.
unicode != utf && utf != 2bytes (utf utf utf'y é diferente) && MSVC não é uma referência
O objectivo do wchar_t é encaixar qualquer carácter suportado num único wchar_t (bem, cerca de pequenos soft à sua maneira), e os fluxos de saída de entrada convertem-se de/para a codificação locale em si mesmos. Sem garantias de tamanho/codificação. Ao aceitar wchar_t em dll, pense se está correcto. A menos, é claro, que seja interessante olhar para além da caixa de areia para o mundo adulto.
Sim, eu sei que Unicode e UTF são codificações diferentes, e supõe-se que sejam diferentes.
Só queria escrever e abreviar a palavra Unicode, por isso acho que não percebi bem.
Embora a referência Unicode diga que a norma inclui caracteres de quase todas as línguas escritas do mundo.
A norma consiste em duas partes principais: o conjunto de caracteres Universal (UCS) e o formato de transformação Unicode (UTF).
Como Unicode já contém uma codificação UTF, coloquei-a dessa forma para tornar a palavra mais curta.
Não sei se o wchar_t* está correcto ou não.
Usou o que está nos exemplos de Renat, a partir do artigo como escrever dll.
mql5 strings estão em Unicode, que contém UTF, por isso penso que é lógico usar wchar_t* no exemplo do artigo.
Para acomodar qualquer carácter suportado num wchar_t.
Não tinha garantias de tamanho/codificação, nem sequer sabia disso, talvez usar Cish short* para a pureza, então ?
Se for correctamente apoiado por MSVC IDE, é claro.
Porque a verdade habitual será engolida pelo ambiente e dar-lhe-á VERDADEIRAMENTE.
UTF-8 e UTF-16 têm a profundidade de bits apropriada.
Em UTF-8, as páginas linguísticas são trocadas por códigos especiais.
O UTF-16 inclui toda a variedade de caracteres ao mesmo tempo.
UTF-8 e UTF-16 têm a profundidade de bits apropriada.
Em UTF-8, as páginas linguísticas são trocadas por códigos especiais.
O UTF-16 inclui toda a variedade de caracteres ao mesmo tempo.
Bem, pelo que percebi do que muitas pessoas escrevem no fórum, as cordas mql5 estão apenas em UTF-16
E na documentação mql eles escrevem:
Uma cadeia de texto é uma sequência de caracteres em formato Unicode com um zero no final.
Devido a isto, é difícil compreender que codificação é na realidade mql5 string.
E se o Unicode já contém todas as famílias de UTF, então porquê até usar a palavra UTF, e introduzir confusão.
Unicode é tudo, claro e simples.
Ou devemos dizê-lo?
Unicode com um bitrate de UTF-16?
Na verdade, alguém dos criadores escreveu anteriormente que
mql tipo string consiste em duas partes, 8 bytes tampão e 4 bytes ponteiro, resultando em 12 bytes.
Eu sei que Unicode e UTF são codificações diferentes.
Tal como acontece, eu queria escrever e abreviar a palavra unicode, provavelmente sem sorte.
Embora a referência Unicode diga que a norma inclui caracteres de quase todas as línguas escritas do mundo.
A norma consiste em duas partes principais: o conjunto de caracteres Universal (UCS) e o formato de transformação Unicode (UTF).
Como Unicode já contém uma codificação UTF, coloquei-a dessa forma para tornar a palavra mais curta.
Não sei se o wchar_t* está correcto ou não.
Usou o que está nos exemplos de Renat, a partir do artigo como escrever dll.
mql5 strings estão em Unicode, que contém UTF, por isso penso que é lógico usar wchar_t * no exemplo do artigo.
Para acomodar qualquer carácter suportado num wchar_t.
Está confuso. O Unicode é uma tabela de caracteres com códigos, que cabia em 0-65535(2 bytes), depois cresceu. E gastar 4 bytes por personagem é gordo. Foi aí que o utf, uma codificação com comprimento variável, veio a calhar (por exemplo, o utf-8 codifica caracteres ASCII com um byte). Por conseguinte, o Unicode (tabela) não contém qualquer utf.
Não tinha garantias de tamanho/codificação, nem sequer sabia disso, talvez usar Cish short* para a pureza, então ?
Se for correctamente apoiado por MSVC IDE, é claro.
Porque a verdade habitual será engolida pelo ambiente e dar-lhe-á VERDADEIRAMENTE.
O padrão inclui char16_t, char32_t, tipos de tamanho fixo. Wchar_t tem um significado diferente.
Como entendi pelo que muitas pessoas escrevem neste fórum, as cordas mql5 estão em UTF-16.
E na documentação mql eles escrevem:
Uma cadeia de texto é uma sequência de caracteres em formato Unicode com um zero no final.
Devido a isto, é difícil compreender que codificação é na realidade mql5 string.
E se o Unicode já contém todas as famílias de UTF, então porquê até usar a palavra UTF, e introduzir confusão.
Unicode é tudo, claro e simples.
Ou deve ser dito dessa forma?
Unicode com taxa de bits UTF-16 ?
Isso não é tudo.
Como ANSI Cyrillic = CP1251, assim
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
Confusão? Não, ainda não ouviu falar.
UTF-8 e UTF-16 têm a profundidade de bits apropriada.
Em UTF-8, as páginas linguísticas são trocadas por códigos especiais.
O UTF-16 inclui toda a variedade de caracteres ao mesmo tempo.
Que páginas de código, do que está a falar? Os "códigos especiais" definem o número de bytes para codificar um carácter porque a codificação é de comprimento variável. O UTF-8 pode codificar qualquer carácter Unicode, bem como o UTF-16. E utf-16 com comprimento variável (pares de substituto).