Na MQL5 há sempre espaço para uma exploração! ;) - página 2

Novo comentário
 
sergeev:

E por isso há a questão número um.

Como se importam funções de 32 bit dlls como user32.dll etc. para uma aplicação de 64? Ou existem cópias para eles no sistema com esse nome e é criado um espaço OOP ?

Bem para começar, os sistemas x64 emularam o lançamento de programas x86. A questão é como executar programas x64 em x86?
 
Urain:
Bem, para começar, os sistemas x64 emularam o lançamento de programas x86. A questão é como executar programas x64 em x86?

Talvez a questão não seja de todo sobre o terminal, mas sobre alguma compilação complicada destas mesmas DLLs?

As DLL's são alimentadas pela API do Windows, e.g. user32, kernel32, winmm, wininet no terminal de 32/64 bits.

A solução do problema parece estar noutro lugar.

 
Urain:
A questão é como executar programas x64 em x86?
Definitivamente não vai funcionar. O processador x86 não pode executar instruções de 64 bits.
sergeev:

Talvez a questão não seja de todo sobre o terminal, mas sobre alguma compilação complicada destas mesmas DLLs?

Por exemplo, utilizador32, kernel32, winmm, wininet trabalham em terminal de 32/64 bit.

A solução para este problema parece estar noutro lugar.

Assim, teoricamente, pode fazer com que as DLLs de 32 bits funcionem ali e ali.

Talvez esteja na altura de chamar os criadores.

Talvez haja formas mais astutas de compilação // Deixei de trabalhar com uma DLL de 32 bits compilada de forma "ingénua" em x64. De qualquer modo, existem precedentes que "existem" (c).

Por exemplo, user32, kernel32, winmm, wininet no terminal de 32/64 bits.

 
MetaDriver:

Então faça-o nessa analogia... nada de especial! :-))

Vou dar uma vista de olhos. ;)

//+------------------------------------------------------------------+
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);
}
//+------------------------------------------------------------------+
A forma mais simples de o aplicar ao seu caso.
 
Yurich:
A versão mais simples para o seu caso.

Bem, para o caso mais simples, crédito: "Estou a anotar-te" :)

De memória, mas não com parcimónia, por comparação. 

    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() возвращает только размер чистого буфера, поэтому по честному добавил размер класса. :)

resultado:

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

A diferença é de 6 vezes. Tendo em conta que tenho um tampão de flutuação - 3 vezes. // Também tem um roubo de memória implícito - a tabela de descritores de classe do seu sistema (neste exemplo) é 1000*1000+1000, enquanto a minha é 1 (!).

A velocidade é quase a mesma.

Estará a encolher? ;)

--

Eu menti, as vossas subclasses são todas estáticas, por isso o roubo implícito é um pouco exagerado. Risque isso. :)

 
MetaDriver:

Talvez esteja na altura de chamar os criadores.
Brevemente.
As funções da biblioteca do sistema para processos x86 (32 bit) têm um invólucro especial através do qual são passados para x64, executados e devolvidos a x86.
 
mql5:
Brevemente.
As funções da biblioteca do sistema para processos x86 (32 bit) têm um invólucro especial, através do qual são transferidos para x64, executados e devolvidos a x86.

Obrigado pela informação.

Pode dizer-me como fazer o mesmo por si próprio? Apenas um link (se disponível).

 
MetaDriver:


Estará a encolher? ;)

Não, utilizo arrays unidimensionais sempre que possível.
 
Não é #ifdef a solução normal para o problema?
 
Yurich:
Não, utilizo arrays unidimensionais sempre que possível.

OK. As questões de optimização são secundárias neste caso. A proeza é defendida de qualquer forma.

--

Posso oferecer-lhe o seguinte problema.

O Array tem uma dimensão arbitrária (vamos limitá-lo a ^16 para maior clareza).

A dimensionalidade é definida na criação por número de parâmetros, como para as matrizes habituais.

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

Deve funcionar para indexadores de todas as dimensões ( A[i][j][k][n][m]....)

Apenas para desporto e treino do cérebro. :)
123456789
Novo comentário