В MQL5 всегда есть место подвигу ! ;) - страница 2

Новый комментарий
 
sergeev:

И поэтому есть вопрос номер один.

Как в 64 приложение происходит импорт функций из 32 битных dll типа  user32.dll  и т.д. Или для них есть копии в системе с таким названием и создается OOP пространство ?

Ну для начала в х64 системах есть эмулированый запуск х86 программ. Вопрос в другом как в х86 запускать х64 программы?
 
Urain:
Ну для начала в х64 системах есть эмулированый запуск х86 программ. Вопрос в другом как в х86 запускать х64 программы?

Может вопрос вообще не в терминале а в каком то хитром компилировании этих самых DLL ?

Ведь работают DLL  от виндовых API.  Наприемр user32,  kernel32,  winmm, wininet  в 32/64 битном терминале.

решение проблемы видать где то лежит в другой плоскости.

 
Urain:
  Вопрос в другом как в х86 запускать х64 программы?
Это точно не получится.  Процессор x86 не может выполнять 64-битные инструкции.
sergeev:

Может вопрос вообще не в терминале а в каком то хитром компилировании этих самых DLL ?

Ведь работают DLL  от виндовых API.  Наприемр user32,  kernel32,  winmm, wininet  в 32/64 битном терминале.

решение проблемы видать где то лежит в другой плоскости.

Вот тут что-то есть.  Т.е. теоретически можно заставить работать 32-битные DLL и там и сям.

Наверное пора звать разработчиков.

// У меня на x64 перестала работать 32-битная DLL скомпиленная "наивным" образом.  Но возможно есть более хитрые способы компиляции.  Во всяком случае прецеденты "имеют место есть" (с) - 

Ведь работают DLL  от виндовых API.  Наприемр user32,  kernel32,  winmm, wininet  в 32/64 битном терминале.

 
MetaDriver:

Ну так сделайте по этой аналогии...  делов-то!... :-))

А я посмотрю. ;)

//+------------------------------------------------------------------+
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);
}
//+------------------------------------------------------------------+
Простейший вариант применительно к вашему случаю.
 
Yurich:
Простейший вариант применительно к вашему случаю.

Ну для простейшего случая - зачёт.  "Я Вас записываю" (с)  :)

По памяти, правда жутко не экономно, для сравнения 

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

результат:

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

Разница в 6 раз.  Учитывая что у меня буфер float - в три.  // и есть ещё  у вас неявный грабёж памяти - системная таблица дескрипторов классов (в данном примере) у вас 1000*1000+1000, а у меня - 1 (!)

Скорость работы практически одинаковая.

Будете уменьшаться? ;)

--

зы.  Пожалуй приврал.  У вас субклассы все статические, так что неявный грабёж несколько преувеличен. Вычёркиваю. :)

 
MetaDriver:

Наверное пора звать разработчиков.
Кратко.
Функции системных библиотек для x86 (32 бита) процессов имеют специальную обёртку, через которую они переходят в x64, выполняются и возвращаются обратно в x86.
 
mql5:
Кратко.
Функции системных библиотек для x86 (32 бита) процессов имеют специальную обёртку, через которую они переходят в x64, выполняются и возвращаются обратно в x86.

Спасибо за инфу.

А не подскажете как такое же самостоятельно сварганить?   Можно просто ссылку (если есть).

 
MetaDriver:


Будете уменьшаться? ;)

Нет, я по возможности использую одномерные массивы.
 
Ну вот разве #ifdef не нормальное решение проблемы?
 
Yurich:
Нет, я по возможности использую одномерные массивы.

Ок. Вопросы оптимизации в данном случае вторичны.  Подвиг защитан по любому.

--

Могу следующую задачку предложить.

Массив произвольной размерности (для определённости ограничим, скажем, до ^16).

Размерность задаётся при создании количеством параметров, как для обычных массивов. 

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

Должны для всех размерностей работать индексаторы  ( A[i][j][k][n][m]....)

Чисто для спорта и тренировки мозгов. :)
123456789
Новый комментарий
Причина обращения: