In MQL5 c'è sempre spazio per un exploit! ;) - pagina 2

 
sergeev:

E così c'è la domanda numero uno.

Come si importano funzioni da dll a 32 bit come user32.dll ecc. in un'applicazione a 64? O ci sono copie per loro nel sistema con quel nome e viene creato uno spazio OOP?

Beh, per cominciare, i sistemi x64 hanno emulato il lancio dei programmi x86. La domanda è come eseguire programmi x64 in x86?
 
Urain:
Beh, per cominciare, i sistemi x64 hanno un lancio emulato dei programmi x86. La domanda è come eseguire programmi x64 in x86?

Forse la domanda non riguarda affatto il terminale ma qualche complicata compilazione di queste stesse DLL?

Le DLL sono alimentate dall'API di Windows, per esempio user32, kernel32, winmm, wininet nel terminale a 32/64 bit.

La soluzione del problema sembra trovarsi altrove.

 
Urain:
La domanda è come eseguire programmi x64 in x86?
Sicuramente non funzionerà. Il processore x86 non può eseguire istruzioni a 64 bit.
sergeev:

Forse la domanda non riguarda affatto il terminale, ma qualche complicata compilazione di queste DLL?

Per esempio, user32, kernel32, winmm, wininet funzionano nel terminale a 32/64 bit.

La soluzione a questo problema sembra trovarsi altrove.

Quindi, teoricamente, si possono far funzionare le DLL a 32 bit lì e lì.

Forse è il momento di chiamare gli sviluppatori.

Forse ci sono modi più astuti di compilazione // Ho smesso di lavorare con una DLL a 32 bit compilata in modo "ingenuo" su x64. Comunque, ci sono precedenti che "esistono" (c).

Per esempio, user32, kernel32, winmm, wininet nel terminale a 32/64 bit.

 
MetaDriver:

Allora fallo in questa analogia... niente di che! :-))

Darò un'occhiata. ;)

//+------------------------------------------------------------------+
class Cdouble
{
public:
        double                  v;
        void    operator=       (double d) {v=d;}
};
//+------------------------------------------------------------------+
class C1Xdouble
{
        Cdouble                 v[];
public:
        
                                C1Xdouble() {}
                                C1Xdouble(int s) {ArrayResize(v,s);}
                               ~C1Xdouble(){ ArrayFree(v);}
        double operator[]       (int x) {return(v[x].v);}
        Cdouble *operator[]    (long x){return(GetPointer(v[(int)x]));}
        int                     Resize(int s){ return(ArrayResize(v,s));}
};
//+------------------------------------------------------------------+
class C2Xdouble
{
        C1Xdouble               v[];
public:
                                C2Xdouble() {}
                                C2Xdouble(int s1,int s2);
                               ~C2Xdouble(){ ArrayFree(v);}
        C1Xdouble *operator[]   (int x) { return(GetPointer(v[x]));}
};
C2Xdouble::C2Xdouble(int s1,int s2)
{
        ArrayResize(v,s1);
        for(int i=0; i<s1; i++) v[i].Resize(s2);
}
//+------------------------------------------------------------------+
Il modo più semplice per applicarlo al vostro caso.
 
Yurich:
La versione più semplice per il vostro caso.

Beh, per il caso più semplice, credito: "ti scrivo" :)

A memoria, ma non con parsimonia, al confronto.

    C2Xdouble  X(1000,1000);
    Print("X(100,100).SizeOF() = ",X.SizeOf()); 
// добавил в ваши классы вычисление размера
-----
    C2DMagicArray  MA(1000,1000);
    Print("MA(100,100).SizeOF() = ",sizeof(MA)+MA.SizeOf()); 
// это мой. у меня MA.SizeOf() возвращает только размер чистого буфера, поэтому по честному добавил размер класса. :)

risultato:

2012.05.23 12:59:05     CXDouble (AUDNZD,M1)    MA(100,100).SizeOF() = 4000112
2012.05.23 12:59:05     CXDouble (AUDNZD,M1)    X(100,100).SizeOF() = 24068068

La differenza è di 6 volte. Tenendo conto che ho un buffer float - 3 volte. // Avete anche una rapina di memoria implicita - la vostra tabella di sistema dei descrittori di classe (in questo esempio) è 1000*1000+1000, mentre la mia è 1 (!).

La velocità è quasi la stessa.

Si ridurrà? ;)

--

Ho mentito, le tue sottoclassi sono tutte statiche, quindi la rapina implicita è un po' esagerata. Cancella tutto. :)

 
MetaDriver:

Forse è il momento di chiamare gli sviluppatori.
Brevemente.
Le funzioni della libreria di sistema per i processi x86 (32 bit) hanno un wrapper speciale attraverso il quale vengono passate a x64, eseguite e restituite a x86.
 
mql5:
Brevemente.
Le funzioni della libreria di sistema per i processi x86 (32 bit) hanno un wrapper speciale, attraverso il quale vengono trasferite a x64, eseguite e restituite a x86.

Grazie per le informazioni.

Puoi dirmi come fare lo stesso per conto tuo? Solo un link (se disponibile).

 
MetaDriver:


Si ridurrà? ;)

No, uso array monodimensionali quando possibile.
 
Non è #ifdef la soluzione normale al problema?
 
Yurich:
No, uso array monodimensionali quando possibile.

OK. Le questioni di ottimizzazione sono secondarie in questo caso. L'impresa è difesa comunque.

--

Posso offrirvi il seguente problema.

Array ha una dimensionalità arbitraria (limitiamola a ^16 per chiarezza).

La dimensionalità è impostata alla creazione dal numero di parametri, come per i soliti array.

XXArray  xx2(5,7),  xx5(12,12,16,16,8);

Dovrebbe funzionare per tutti gli indicizzatori di dimensioni ( A[i][j][k][n][m]....)

Solo per lo sport e l'allenamento del cervello. :)