Domande da un "manichino" - pagina 14

Nuovo commento
 

Ecco un'altra cosa a cui pensare: fatelo!// Riporta i risultati. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

Sono onestamente sconcertato, ragazzi, state solo giocando alla pari. Totalmente piatto.

Volevo solo scusarmi e intromettermi in questa conversazione "seria". Ma mentre ero fuori a prendere le sigarette, sono stato battuto.

E non è che siamo dei "manichini", vero? E questo "boo-boo-boo" è stato fatto dal nulla.

Nella classe CExpert, lo correggo in ulong.

 
Renat:

Vi sbagliate.

Sì, ho dimenticato la conversione del tipo.

 
uncleVic:

E non è "dummies", vero?

Sono un idiota sotto molti aspetti. Quindi non capisco come le funzioni destinate a restituire long restituiscano ULONG_MAX-1. Le insidie di una gestione superficiale dei tipi interi sono scritte quasi nel manuale stesso. sergeev ha colto correttamente il motivo della domanda: il controllo dell'ordine. Se imposto request.magic al tipo ulong, allora mi aspetto che anche le funzioni HistoryDealGetInteger(), PositionGetInteger() e OrderGetInteger() restituiscano il tipo ulong. Senza conversioni di tipo esplicito-implicito.

Tuttavia, se isuoi esempi spiegano che le conversioni di tipo long<->ulong non causano la perdita di valori (a differenza di double -> int, per esempio), allora l'ulteriore processo di pensiero diventa chiaro.

zioVic:

E un tale "bubbone" è stato creato su uno spazio vuoto.

In realtà il thread "Dummie's Questions" è stato scelto per ottenere spiegazioni, non ammonizioni.

 
Yedelkin:

Sono un idiota per molte cose. Quindi non capisco come le funzioni destinate a restituire long restituiscano ULONG_MAX-1. Le insidie di una gestione superficiale dei tipi interi sono scritte quasi nel manuale stesso. sergeev ha colto correttamente il motivo della domanda: il controllo dell'ordine. Se imposto request.magic al tipo ulong, allora mi aspetto che anche le funzioni HistoryDealGetInteger(), PositionGetInteger() e OrderGetInteger() restituiscano il tipo ulong. Senza conversioni di tipo esplicito-implicito.

Tuttavia, se isuoi esempi spiegano che le conversioni di tipo long<->ulong non causano la perdita di valori (a differenza, per esempio, di double -> int), allora l'ulteriore processo di pensiero diventa chiaro.

In realtà, il thread "Dummie's Questions" è stato scelto a scopo di chiarimento, non di rimprovero.

Offeso? Mi dispiace, non ho potuto farne a meno.
 
uncleVic:
Ti sei offeso? Mi dispiace, non ho potuto farne a meno.
No, non lo sono. Ho avuto la mia parte di battaglie su internet. Cerco sempre di indirizzare la discussione in una direzione costruttiva, per così dire.
 
sergeev:

In realtà non è 64 ma solo 63 bit (cioè un 8 byte incompleto). 8 byte sarebbero se si usasse l'intero intervallo lungo.

Ma purtroppo...

Da un lato, l 'ulong magico viene passato nella struttura MqlTradeRequest. Significa che si possono impostare solo valori positivi.

D'altra parte, le funzioni PositionGetInteger/OrderGetInteger restituiscono il tipo long. Significa che la metà della gamma ulong è tagliata fuori.

In tutto, abbiamo 63 bit invece dei 64 bit descritti sopra. In realtà, non è tanto male quanto un grande inconveniente per i principi del controllo dell'ordine.

Sarebbe molto più conveniente usare lo stesso sistema di MT4 - consentire ai maghi con un segno. Poiché molti sistemi di trading si basano su un semplice principio che utilizza il simbolo stesso di un mago. Poiché è molto più facile dividere un sistema in due e filtrare gli ordini usando la solita funzione MathAbs( OrderMagicNumber() ).

tutti 64. È un dato di fatto. Non aggrappatevi al tipo firmato o non firmato. Questo serve al compilatore per assicurarsi che le operazioni aritmetiche siano corrette (e c'è uno spostamento di bit a destra in logica o aritmetica, a seconda dei valori firmati).

Nessuna informazione viene persa durante il trasferimento (assegnazione) e le fusioni senza segno di dati della stessa dimensione. Prova a far rimbalzare ULONG_MAX avanti e indietro. Prova l'assegnazione di long-ulong e ritorno. Prova a copiare la struttura.

La cosa migliore è assicurarsi da soli. Allora la questione sarà risolta una volta per tutte.

 
MetaDriver:

Ecco un'altra cosa a cui pensare: fatelo!// Riporta i risultati. ;)

Fatto! Sostituite la linea 14 del codice con L.l = 4548887299649496524.

Segue dalla descrizione della struttura MqlTradeRequest che magic è di tipo ulong, cioè può essere assegnato a valori maggiori del valore costante LONG_MAX. Tuttavia, le funzioni ... Le funzioniGetInteger() sono progettate per lavorare con il tipo lungo, quindi i valori magici saranno implicitamente castati al tipo lungo da queste funzioni. Ma siccome c'è una corrispondenza uno-a-uno tra le variabili di tipo long e ulong, quando si confronta il valore magico con il risultato restituito dalle funzioni di ...GetInteger() ,possiamo tranquillamente usare una conversione di tipo esplicita (per esempio: magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Grazie per aver mostrato ripetutamente degli esempi.

 

stringo:

Durante il trasferimento (assegnazione) dei dati, così come il casting senza segno di dati della stessa dimensione, nessuna informazione viene persa da nessuna parte. Prova a far rimbalzare ULONG_MAX avanti e indietro. Prova l'assegnazione di long-ulong e ritorno. Prova a copiare la struttura. Convincetevi da soli e non diffondete miti.

L'ho già provato e restituisce il risultato necessario quando si forza il tipo (beh, forse un'altra "danza con i diamanti" dovrà essere fatta in aggiunta). Ma non è così importante).

zioVic:

Cambierò la classe CExpert in ulong.

Penso che sia una buona idea, coloro che usano valori negativi nella magia dovranno specificare forzatamente cosa devono restituire/impostare.

Sarebbe anche molto bello se la documentazione indicasse non solo long o ulong, ma entrambi questi tipi (ad esempio così "long / ulong").

 
stringo:

Nessuna informazione viene persa da nessuna parte durante il trasferimento dei dati (assegnazione), o durante il casting senza caratteridi dati della stessa dimensione.

Un'ulteriore domanda: c'è un modo elegante per preservare le informazioni quando si trasferisce il doppio -> lungo?
1...789101112131415161718192021...277
Nuovo commento