La nuova sintassi MQL4 - pagina 3

Nuovo commento
 

Ho una domanda sui tipi di variabili, int, uint, char, short ushort ecc. Il nuovo compilatore dà avvertimenti sulla possibile perdita di dati a causa della conversione dei tipi, quindi è una buona pratica per;

a) usare quello che meglio si adatta ai requisiti della variabile o,

b) evitare la conversione tra tipi e quindi usare int per tutto. (beh, tutto ciò che non ha bisogno di una virgola mobile)

 
SDC:

Ho una domanda sui tipi di variabili, int, uint, char, short ushort ecc, è la pratica migliore per;

a) usare quello che si adatta meglio ai requisiti della variabile o

b) evitare la conversione tra tipi e quindi usare int per tutto. (beh, tutto ciò che non ha bisogno di una virgola mobile)

Se hai bisogno di un unsigned long un int non lo taglierà... usa il tipo corretto e la conversione esplicita del tipo. IMO
 

Per conversione esplicita del tipo intendi fare la conversione prima di qualsiasi calcolo tra tipi diversi?

 
RaptorUK:
Se avete bisogno di un unsigned long un int non lo taglierà... usate il tipo corretto e la conversione esplicita del tipo. IMO

Concordare.
 
SDC:

Per conversione esplicita del tipo intendi fare la conversione prima di qualsiasi calcolo tra tipi diversi?

Vedi qui: https: //www.mql5.com/en/docs/basis/types/casting
 

Buon articolo grazie angevoyageur lo leggerò bene quando torno a casa dal lavoro.

 
SDC:

Per conversione esplicita del tipo intendi fare la conversione prima di qualsiasi calcolo tra tipi diversi?

No, voglio dire che puoi convertire un ulong in un int in questo modo.

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

Ok, sì, è quello che pensavo intendessi.

A parte il fatto che non stavo davvero chiedendo di ulong. Raramente, se mai, avrei bisogno di lavorare con valori così grandi che non potrebbero essere accomodati da un intero a 32 bit. Non so nemmeno come dire il numero che un intero a 64 bit può contenere lol...

Probabilmente avrei dovuto essere più specifico, non ho avuto il tempo questa mattina di scrivere la mia domanda in modo corretto, ma ora sono a casa lo farò.

Nel vecchio mql4 usavamo gli interi per tutto. Scriveremmo for(int i=0; i<100; i++) Non abbiamo bisogno di valori negativi, e non abbiamo bisogno di un valore più grande di 100 quindi potremmo usare un uchar per quello. Questo significa che è quello che dovremmo fare?

Quando guardo il codice di altri programmatori, molti di loro sembrano usare tipi interi a 32 bit su tutta la linea. C'è una ragione valida per questo? Cosa sanno che io devo ancora scoprire? Usare i tipi di variabili con l'impronta più piccola in tutto il programma crea un mal di testa di problemi di typecasting per nessuna ragione se non una dimensione di file leggermente più piccola? O si risparmia un sacco di RAM? E' sicuro assumere che finché il valore di un tipo può essere accomodato da un altro tipo è giusto farlo? Il typecasting tra tipi diversi usa molta più CPU che usare lo stesso tipo?

Aggiornamento: ho cercato questo ho letto questa risposta a una domanda simile su stackoverflow.com

"Performance-wise, un int è più veloce in quasi tutti i casi. La CPU è progettata per lavorare in modo efficiente con valori a 32 bit.

I valori più corti sono complicati da gestire. Per leggere un singolo byte, diciamo, la CPU deve leggere il blocco di 32 bit che lo contiene, e poi mascherare i 24 bit superiori.

Per scrivere un byte, deve leggere il blocco di 32 bit di destinazione, sovrascrivere gli 8 bit inferiori con il valore del byte desiderato, e scrivere di nuovo l'intero blocco di 32 bit.

Dal punto di vista dello spazio, ovviamente, si risparmia qualche byte usando tipi di dati più piccoli. Quindi se state costruendo una tabella con qualche milione di righe, allora può valere la pena considerare tipi di dati più corti. (E la stessa potrebbe essere una buona ragione per cui dovreste usare tipi di dati più piccoli nel vostro database)

E dal punto di vista della correttezza, un int non trabocca facilmente. Cosa succede se pensate che il vostro valore rientri in un byte, e poi ad un certo punto nel futuro qualche innocuo cambiamento al codice significa che valori più grandi vengono memorizzati in esso?

Queste sono alcune delle ragioni per cui int dovrebbe essere il vostro datatype di default per tutti i dati integrali. Usate byte solo se volete effettivamente memorizzare byte macchina. Usate short solo se avete a che fare con un formato di file o un protocollo o simili che specificano effettivamente valori interi a 16 bit. Se avete solo a che fare con gli interi in generale, fateli ints".

 
SDC:

Ok, sì, è quello che pensavo intendessi.

A parte il fatto che non stavo davvero chiedendo di ulong. Raramente, se mai, avrei bisogno di lavorare con valori così grandi che non potrebbero essere accomodati da un intero a 32 bit. Non so nemmeno come dire il numero che un intero a 64 bit può contenere lol...

Probabilmente avrei dovuto essere più specifico, non ho avuto il tempo questa mattina di scrivere la mia domanda in modo corretto, ma ora sono a casa lo farò.

Nel vecchio mql4 usavamo gli interi per tutto. Scriveremmo for(int i=0; i<100; i++) Non abbiamo bisogno di valori negativi, e non abbiamo bisogno di un valore più grande di 100 quindi potremmo usare un uchar per quello. Questo significa che è quello che dovremmo fare?

uchar - Unsigned Character, perché dovreste usarlo per un ciclo? Non ha senso per me... usate un int. Lavorerai con gli ulong, che è quello che è un nuovo datetime . . . e quando fai typecast senza pensarci in futuro verrai avvertito . . . affronta l'avvertimento o ignoralo. Non sperare solo nel meglio però, fai come stai facendo ora, impara e comprendi

La roba che hai postato da stackoverflow ha senso per me, penso che sia un buon consiglio.

 
SDC: Il typecasting tra tipi diversi usa molta più CPU che usare lo stesso tipo?

Tra diverse dimensioni usa più CPU, non molto di più. Solo diverse istruzioni come il citato 32 bit fetch, isolate, operate, place, write, quando si modificano i char in una struttura. Proprio come moltiplicare per 0,5 usa leggermente meno CPU che dividere per 2,0

Salvare 16 bit per elemento di array non ha senso sulle macchine GB, l'ho fatto quando ho implementato applicazione, database, GUI (vt100) in 8 KB (sic.) Andare a 64 bit per (per tutto,) non avrà senso fino a quando le piattaforme a 128 bit saranno comuni.

Signed vs unsigned non c'è differenza. È solo un'assegnazione, nessun bit viene cambiato. La differenza è il codice che usa la variabile. Ad esempio A[indice] fa Indirizzo(a) + indice * sizeof(a[0]) dove il più è un'addizione con segno o senza segno.

Per chiarezza di codifica, userei uint per indicizzare gli array poiché A[-1] non ha senso, ma poi il conteggio alla rovescia è problematico FOR(uint iA=n; iA >= 0; iA--){} iA>=0 è sempre vero.

Usate int (o uint) a meno che non sia necessario per altre ragioni.
123456
Nuovo commento
Motivazione: