Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 163

 
Nikolai Semko:

No, l'avrei notato. Anche se non escludo che in alcuni casi (quando si lavora con Unicode) questo sia possibile. In Java, per esempio, il tipo char è 2 byte.
Ho provato ad analizzare i dati dal crypto-exchange in due varianti: tramite questa libreria JSON e tramite il lavoro con l'array di char.
La differenza si è rivelata essere 700(!!!) volte per la velocità. Ero scioccato. Forse era lontano dalla migliore implementazione JSON.


Il carattere è 16LE e le stringhe sono ovviamente da pascal. Tra l'altro e gli array di Fortran

 
Nikolai Semko:

No, l'avrei notato. Anche se non escludo che in alcuni casi (quando si lavora con Unicode) questo sia possibile. In Java, per esempio, il tipo char è 2 byte.
Ho provato ad analizzare i dati da crypto-exchange in due varianti: tramite questa libreria JSON e tramite il lavoro con l'array di char.
La differenza si è rivelata essere 700(!!!) volte per la velocità. Ero scioccato. Forse era lontano dalla migliore implementazione JSON.

Quando si passa una stringa mql alla dll, dalla parte della dll, il tipo di stringa mql viene preso come wchar_t*.
E il type size mismatch non si trova solo in Java, dipende dal tipo di architettura, non ricordo quale, o dal sistema operativo, o dal ferro.

700 volte? Wow, stavo mettendo da parte questa libreria per l'analisi JSON, non ne vale la pena?
Ed è meglio tradurreStringToCharArray e analizzare l'array in loop?

 
Roman:

700 volte? Wow, ho appena messo da parte questa libreria per l'analisi JSON, quindi non ne vale la pena?
Ed è meglio tradurreStringToCharArray e analizzare l'array in loop?

Credo di sì. Anche se si dovrebbe sempre controllare. Effettuare alcune misurazioni. Non escludo che le funzioni di stringa non fossero scritte nel modo migliore, e ora sono state sistemate.
Ho preso queste misure più di un anno fa.

Il codice sarà ovviamente più grande quando si lavora con gli array di char, ma le possibilità sono più flessibili.

 
Roman:

E molto probabilmente sotto mql string c'è short[] o wchar_t[] o wchar_t*.
Dopo tutto, le stringhe mql sono in Unicode, mentre utf è di 2 byte.
E StringToCharArray converte da short[] a char[].

unicode != utf && utf != 2 byte (utf non è uguale a utf) && MSVC non è uno standard

Il punto di wchar_t è quello di inserire qualsiasi carattere supportato in un singolo wchar_t (beh, circa smallsoft a modo loro), e i flussi di input output convertono da/verso la codifica locale da soli. Nessuna garanzia di dimensione/codifica. Quando accettate wchar_t in dll, pensate se è corretto. A meno che, naturalmente, non sia interessante guardare oltre la sandbox nel mondo degli adulti.

 
Vict:

unicode != utf && utf != 2 byte (utf utf'y è diverso) && MSVC non è un riferimento

Il punto di wchar_t è quello di inserire qualsiasi carattere supportato in un singolo wchar_t (beh, circa smallsoft a modo loro), e i flussi di uscita in ingresso convertono da/verso la codifica locale stessa. Nessuna garanzia di dimensione/codifica. Quando accettate wchar_t in dll, pensate se è corretto. A meno che, naturalmente, non sia interessante guardare oltre la sandbox nel mondo degli adulti.

Sì, so che Unicode e UTF sono codifiche diverse, e si suppone che siano diverse.
Volevo solo scrivere e abbreviare la parola Unicode, quindi credo di non aver capito bene.

Anche se il riferimento Unicode dice che lo standard include caratteri di quasi tutte le lingue scritte del mondo.
Lo standard consiste di due parti principali: il set di caratteri universale (UCS) e il formato di trasformazione Unicode (UTF).

Poiché Unicode contiene già una codifica UTF, l'ho messa così per rendere più breve l'ortografia della parola.

Non so se wchar_t* è corretto o no.
Usato quello che c'è negli esempi di Renat, dall'articolo come scrivere dll.
Le stringhe di mql5 sono in Unicode, che contiene UTF, quindi penso che sia logico usare wchar_t* nell'esempio dell'articolo.
Per ospitare qualsiasi carattere supportato in un wchar_t.

Riguardo all'assenza di garanzie di dimensione/codifica, non lo sapevo nemmeno, forse usare Cish short* per la purezza allora?
Se sarà correttamente supportato dall'IDE MSVC, naturalmente.
Perché il solito vero sarà inghiottito dall'ambiente e lo darà VERO.

 

UTF-8 e UTF-16 hanno la profondità di bit appropriata.

In UTF-8 le pagine di lingua sono scambiate da codici speciali.

UTF-16 include l'intera varietà di caratteri allo stesso tempo.

 
Edgar Akhmadeev:

UTF-8 e UTF-16 hanno la profondità di bit appropriata.

In UTF-8 le pagine di lingua sono scambiate da codici speciali.

UTF-16 include l'intera varietà di caratteri allo stesso tempo.

Beh, come ho capito da quello che molte persone scrivono sul forum, le stringhe mql5 sono solo in UTF-16
E nella documentazione mql scrivono:
Una stringa di testo è una sequenza di caratteri in formato Unicode con uno zero alla fine.
A causa di questo, è difficile capire quale codifica è effettivamente la stringa mql5.
E se Unicode contiene già tutte le famiglie di UTF, allora perché persino usare la parola UTF, e introdurre confusione.
Unicode è tutto, chiaro e semplice.
O dovremmo dire così?
Unicode con un bitrate di UTF-16?

In realtà qualcuno degli sviluppatori ha scritto prima che
Il tipo di stringa mql consiste di due parti, buffer 8 byte e puntatore 4 byte, risultante in 12 byte.

 
Roman:

So che Unicode e UTF sono codifiche diverse.
Guarda caso, volevo scrivere e abbreviare la parola unicode, probabilmente non è una fortuna.

Anche se il riferimento Unicode dice che lo standard include caratteri di quasi tutte le lingue scritte del mondo.
Lo standard consiste di due parti principali: il set di caratteri universale (UCS) e il formato di trasformazione Unicode (UTF).

Poiché Unicode contiene già una codifica UTF, l'ho messa così per accorciare la parola.

Non so se wchar_t* è corretto o no.
Usato quello che negli esempi di Renat, dall'articolo come scrivere dll.
Le stringhe di mql5 sono in Unicode, che contiene UTF, quindi penso che sia logico usare wchar_t * nell'esempio dell'articolo.
Per ospitare qualsiasi carattere supportato in un wchar_t.

Siete confusi. Unicode è una tabella di caratteri con codici, prima stava in 0-65535(2 byte), poi è cresciuto. E spendere 4 byte per carattere è grasso. È qui che utf, una codifica con lunghezza variabile, è tornata utile (per esempio, utf-8 codifica i caratteri ASCII con un byte). Pertanto l'Unicode (tabella) non contiene alcun utf.

Riguardo all'assenza di garanzie di dimensione/codifica, non lo sapevo nemmeno, forse usare Cish short* per la purezza allora?
Se sarà correttamente supportato dall'IDE MSVC, naturalmente.
Perché il solito vero sarà inghiottito dall'ambiente e lo darà VERO.

Lo standard include char16_t, char32_t, tipi a dimensione fissa. Wchar_t ha un significato diverso.

 
Roman:

Come ho capito da quello che molte persone scrivono su questo forum, le stringhe mql5 sono in UTF-16.
E nella documentazione mql scrivono:
Una stringa di testo è una sequenza di caratteri in formato Unicode con uno zero alla fine.
A causa di questo, è difficile capire quale codifica è effettivamente la stringa mql5.
E se Unicode contiene già tutte le famiglie di UTF, allora perché persino usare la parola UTF, e introdurre confusione.
Unicode è tutto, chiaro e semplice.
O si dovrebbe dire così?
Unicode con bit rate UTF-16 ?

Non è tutto.

Come ANSI Cyrillic = CP1251, così

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

Confusione? No, non ho sentito.

 
Edgar Akhmadeev:

UTF-8 e UTF-16 hanno la profondità di bit appropriata.

In UTF-8 le pagine di lingua sono scambiate da codici speciali.

UTF-16 include l'intera varietà di caratteri allo stesso tempo.

Quali pagine di codice, di cosa stai parlando? I "codici speciali" definiscono il numero di byte per codificare un carattere perché la codifica è di lunghezza variabile. UTF-8 può codificare qualsiasi carattere Unicode così come UTF-16. E utf-16 con lunghezza variabile (coppie surrogate).

Motivazione: