¡En MQL5 siempre hay espacio para un exploit ! ;) - página 2

Nuevo comentario
 
sergeev:

Y ahí está la pregunta número uno.

¿Cómo se importan funciones de dlls de 32 bits como user32.dll etc. a una aplicación de 64? ¿O hay copias para ellos en el sistema con ese nombre y se crea un espacio OOP?

Bueno, para empezar, los sistemas x64 tienen un lanzamiento emulado de los programas x86. La cuestión es cómo ejecutar programas x64 en x86.
 
Urain:
Bueno, para empezar, los sistemas x64 tienen un lanzamiento emulado de los programas x86. La cuestión es cómo ejecutar programas x64 en x86.

¿Quizás la pregunta no sea sobre el terminal sino sobre alguna compilación complicada de estas mismas DLLs?

Las DLL se alimentan de la API de Windows, por ejemplo, user32, kernel32, winmm, wininet en el terminal de 32/64 bits.

La solución del problema parece estar en otra parte.

 
Urain:
La cuestión es cómo ejecutar programas x64 en x86.
Definitivamente no funcionará. El procesador x86 no puede ejecutar instrucciones de 64 bits.
sargazo:

¿Puede ser que la pregunta no sea sobre el terminal, sino sobre alguna compilación complicada de estas mismas DLLs?

Por ejemplo, user32, kernel32, winmm, wininet funcionan en un terminal de 32/64 bits.

La solución a este problema parece estar en otra parte.

Así que, teóricamente, puedes hacer que las DLL de 32 bits funcionen allí y allí.

Quizás sea el momento de llamar a los desarrolladores.

Tal vez haya formas más astutas de compilación // Dejé de trabajar con una DLL de 32 bits compilada de forma "ingenua" en x64. De todos modos, hay precedentes que "existen" (c).

Por ejemplo, user32, kernel32, winmm, wininet en el terminal de 32/64 bits.

 
MetaDriver:

Así que hazlo en esa analogía... ¡no es gran cosa!... :-))

Voy a echar un vistazo. ;)

//+------------------------------------------------------------------+
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);
}
//+------------------------------------------------------------------+
La forma más sencilla de aplicarlo a su caso.
 
Yurich:
La versión más sencilla para su caso.

Bueno, para el caso más sencillo, crédito. "Te apunto" :)

De memoria, pero no escasa, en comparación. 

    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

La diferencia es de 6 veces. Teniendo en cuenta que tengo un buffer de flotación - 3 veces. // También tienes un robo de memoria implícito - tu tabla de descriptores de clase del sistema (en este ejemplo) es 1000*1000+1000, mientras que la mía es 1 (!).

La velocidad es casi la misma.

¿Se va a encoger? ;)

--

Mentí, sus subclases son todas estáticas, así que el robo implícito es un poco exagerado. Tacha eso. :)

 
MetaDriver:

Quizás sea el momento de llamar a los desarrolladores.
Brevemente.
Las funciones de la biblioteca del sistema para los procesos x86 (32 bits) tienen una envoltura especial a través de la cual se pasan a x64, se ejecutan y se devuelven a x86.
 
mql5:
Brevemente.
Las funciones de la biblioteca del sistema para los procesos x86 (32 bits) tienen una envoltura especial, a través de la cual se transfieren a x64, se ejecutan y se devuelven a x86.

Gracias por la información.

¿Puede decirme cómo hacer lo mismo por su cuenta? Sólo un enlace (si está disponible).

 
MetaDriver:


¿Se va a encoger? ;)

No, utilizo matrices unidimensionales siempre que es posible.
 
¿No es #ifdef la solución normal al problema?
 
Yurich:
No, utilizo matrices unidimensionales siempre que es posible.

DE ACUERDO. Las cuestiones de optimización son secundarias en este caso. La hazaña se defiende de todos modos.

--

Puedo ofrecerle el siguiente problema.

La matriz tiene una dimensionalidad arbitraria (vamos a limitarla a ^16 para mayor claridad).

La dimensionalidad se establece en el momento de la creación por el número de parámetros, como en el caso de las matrices habituales.

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

Debería funcionar para todos los indexadores de dimensiones ( A[i][j][k][n][m]....)

Sólo para el deporte y el entrenamiento del cerebro. :)
123456789
Nuevo comentario