mql5: Brevemente. Le funzioni delle librerie di sistema per i processi x86 (32 bit) hanno un wrapper speciale attraverso il quale vengono passate a x64, eseguite e restituite a x86.
Windows a 64 bit ha una cartella chiamata SysWOW64. Questa cartella è destinata alle applicazioni a 32 bit lanciate nel sistema operativo a 64 bit, mentre le librerie e i driver regolari a 64 bit sono memorizzati nella cartella System32. Se il programma è lanciato come un 32 bit, i riferimenti alla cartella System32 sono reindirizzati a SysWOW64.
Per farla breve, il problema dei 32/64 bit è diventato acuto in MT5.
questa è una questione molto importante ed è ora che venga affrontata.
o aggiungere una cartella libraries64 in modo che il terminale sappia da dove prendere le librerie o aggiungere qualche modo per disperdere le DLL nelle cartelle system32/SysWow64 o usare #ifdef
La seconda variante è una matrice N-dimensionale (doppia). La struttura dell'array è anche specificata nel costruttore da un altro array (int).
Questa variante è un po' più veloce della precedente. E in questa variante, è più facile creare operazioni con i subarray.
Yurich, sei un tipo in gamba, sono stato distratto dal forum per un paio di giorni e tu hai già fatto un paio di varianti.
Prima impressione - la prima variante è piena di intoppi alla chiamata errata con meno numero di indici: per esempio double x=A[i][j][k]; "chiamata tridimensionale" per array quadridimensionale restituirà double come niente di che, ma da qualsiasi altra posizione dell'array che l'utente voleva.E non è ovvio come rintracciare e gestire tali errori. Ma il vantaggio indiscutibile della prima implementazione è l'economia di memoria. Il secondo modo è molto più dispendioso. Ma, come hai giustamente notato, puoi provare a passare ai subarray in esso e tutte le difficoltà sono abbastanza gestibili in questo caso.
Ho alcune idee, ma non avrò tempo libero fino alla sera prima, se ci arrivo. Ma ci arriveremo, lo prometto. :)
--
Idea di base: usare un'altra classe, qualcosa come "left indexes controller", e l'indice più a destra da processare dalla classe principale (se funziona, altrimenti un'altra classe per l'indice destro). Così facendo, l'array base double (unidimensionale e l'unico) dovrebbe essere reso un membro della classe principale CNArray. Qualcosa del genere.
Tx. prima impressione - la prima variante è irta di glitch alla chiamata errata con meno numero di indici: cioè per esempio doppio x=A[i][j][k]; "chiamata tridimensionale" per array quadridimensionale restituirà doppio come se nulla fosse successo, ma allo stesso tempo dalla posizione dell'array che l'utente voleva. Inoltre, per rintracciare e gestire tali errori non è visibile in che modo.
Ho giocato con il primo metodo di Yurich e sembra che sia possibile controllare il rango dell'array in questo modo:
class DinArr_Double{
doublevalue[];
int size[];
int index;
int ivalue;
int range;
bool checkerror;
public:
DinArr_Double(constint &n[]);
~DinArr_Double() { ArrayFree(value); ArrayFree(size);}
doubleoperator[](long x_);
DinArr_Double* operator[](int x_);
voidoperator= (double d) { value[ivalue]=d; index=0; ivalue=0;}
};
//+------------------------------------------------------------------+
DinArr_Double::DinArr_Double(constint &n[]){
int m=1, k=ArraySize(n);
range = ArraySize(n);
ArrayResize(size,k);
size[k-1]=1;
for(int i=k-2; i>=0; i--) size[i]=n[i+1]*size[i+1];
for(int i=0; i<k; i++) m*=n[i];
ArrayResize(value,m);
index=0;
ivalue=0;
checkerror = false;
}
//+------------------------------------------------------------------+double DinArr_Double::operator[](long x_){
index=0;
int i=ivalue;
ivalue=0;
return(value[i+(int)x_]);
}
//+------------------------------------------------------------------+
DinArr_Double* DinArr_Double::operator[](int x_){
ivalue+=x_*size[index++];
Brevemente.
Le funzioni delle librerie di sistema per i processi x86 (32 bit) hanno un wrapper speciale attraverso il quale vengono passate a x64, eseguite e restituite a x86.
Per farla breve, il problema dei 32/64 bit è diventato acuto in MT5.
questa è una questione molto importante ed è ora che venga affrontata.
o aggiungere una cartella libraries64 in modo che il terminale sappia da dove prendere le librerie
o aggiungere qualche modo per disperdere le DLL nelle cartelle system32/SysWow64
o usare #ifdef
https://www.mql5.com/ru/forum/6729#comment_199764
ZS.
applicazione a SD #381730
Array di qualsiasi dimensione (per chiarezza, diciamo che lo limitiamo a ^16).
La dimensionalità è impostata alla creazione dal numero di parametri, come per gli array normali.
XXArray xx2(5,7), xx5(12,12,16,16,8);
Gli indicizzatori dovrebbero funzionare per tutte le dimensioni ( A[i][j][k][n][m]....)
Bene, visto che la comunità tace, continuerò...
Uno schema di una classe di array N-dimensionale (doppio) e un test per testarlo.
La dimensionalità è descritta da (int) array nel costruttore.
La seconda variante è una matrice N-dimensionale (doppia). La struttura dell'array è anche specificata nel costruttore da un altro array (int).
Questa variante è un po' più veloce della precedente. E in questa variante è più facile creare operazioni con i subarray.
La seconda variante è una matrice N-dimensionale (doppia). La struttura dell'array è anche specificata nel costruttore da un altro array (int).
Questa variante è un po' più veloce della precedente. E in questa variante, è più facile creare operazioni con i subarray.
Yurich, sei un tipo in gamba, sono stato distratto dal forum per un paio di giorni e tu hai già fatto un paio di varianti.
Prima impressione - la prima variante è piena di intoppi alla chiamata errata con meno numero di indici: per esempio double x=A[i][j][k]; "chiamata tridimensionale" per array quadridimensionale restituirà double come niente di che, ma da qualsiasi altra posizione dell'array che l'utente voleva.E non è ovvio come rintracciare e gestire tali errori. Ma il vantaggio indiscutibile della prima implementazione è l'economia di memoria. Il secondo modo è molto più dispendioso. Ma, come hai giustamente notato, puoi provare a passare ai subarray in esso e tutte le difficoltà sono abbastanza gestibili in questo caso.
Ho alcune idee, ma non avrò tempo libero fino alla sera prima, se ci arrivo. Ma ci arriveremo, lo prometto. :)
--
Idea di base: usare un'altra classe, qualcosa come "left indexes controller", e l'indice più a destra da processare dalla classe principale (se funziona, altrimenti un'altra classe per l'indice destro). Così facendo, l'array base double (unidimensionale e l'unico) dovrebbe essere reso un membro della classe principale CNArray. Qualcosa del genere.
Tx. prima impressione - la prima variante è irta di glitch alla chiamata errata con meno numero di indici: cioè per esempio doppio x=A[i][j][k]; "chiamata tridimensionale" per array quadridimensionale restituirà doppio come se nulla fosse successo, ma allo stesso tempo dalla posizione dell'array che l'utente voleva. Inoltre, per rintracciare e gestire tali errori non è visibile in che modo.
Ho giocato con il primo metodo di Yurich e sembra che sia possibile controllare il rango dell'array in questo modo:
Compito:
- Per passare un array di numeri dall'Expert Advisor all'indicatore.
Requisiti.
Non usare
- eventi del grafico,
- file,
- variabili globali (note anche come file),
- dll
Compito:
- Per passare un array di numeri dall'Expert Advisor all'indicatore.
Requisiti.
- Non usare eventi del grafico, file, dll per il trasferimento dei dati
Poi rimangono i canali nominati.
Compito:
- Per passare un array di numeri dall'Expert Advisor all'indicatore.
Condizioni.
Non usare
- eventi del grafico,
- file,
- variabili globali (alias file),
- dll
Non c'è nessuno che lo faccia :)
Allora propongo un'altra variante - usare la sottocartina e le funzioniChartSetString()eChartGetString().