Я читал. Спасибо что напомнил, сейчас сижу перечитываю. Возможно буду этот механизм юзать (только модифицирую слегка).
Что до "фицияльного" внедрения этой фишки в mql5 - сильно сомневаюсь. Здесь используется работа с указателями, которых в mql нет и не будет (мой прогноз).
Ибо управляемый доступ к памяти, является одной из основопологающих концепций mql-программирования с позиций МетаКвотов (Ренат, поправьте, если неправ). И то, что они лояльно относятся к подобному хакерству (хотя и достаточно интеллегентному), вовсе не означает, что они будут внедрять эти же механизмы в "фицияльный" mql. Мне кажется, даже "хорошо обёрнутая" реализация подобного механизма, повлечёт за собой как минимум декларирование какого-то нового механизма разделения памяти, со своими mql-правилами доступа (включая набор соответствующих ограничений). Хотя это и возможно. Почему бы и нет.
А в плане запроса к разработчикам "давайте уже что-то делать, нужен нормальный совместный доступ к массивам" - я горячо поддерживаю. Да, доступ к "соседям" нужен. Да, очень нужен. Да, желательно решать на уровне mql...
Указатели есть но они обёрнуты чтоб отстранить программиста от прямого доступа к данным.
Если применить тот же механизм оборачивания то и передачу указателя через событие можно будет точно так же закамуфлировать.
Похожий механизм кстати уже реализован при работе с классами.
class C_A
{
public:
C_A(void){};
~C_A(void){};
double a;
};
//+------------------------------------------------------------------+class C_C
{
public:
C_A *ua;
C_C(void){};
~C_C(void){};
void InitC_C(C_A *ua_){ua=ua_;};
};
//+------------------------------------------------------------------+voidOnStart()
{
//---
C_A a; a.a=123.3; // присвоим значение в класс А
C_C c; c.InitC_C(GetPointer(a)); // передадим указатель и свяжим данные
Print("CC=",c.ua.a); // получим данные уже из класса С
c.ua.a=456.3; // изменим переменную в классе С
Print("CA=",a.a); // получим эти изменения в классе А
}
Все объекты в MQL5 по умолчанию передаются по ссылке, но есть возможность использовать и указатели объектов. При этом есть опасность получить в качестве параметра функции указатель неинициализированного объекта. В этом случае работа программы будет завершена критически с последующей выгрузкой. Автоматически создаваемые объекты как правило такой ошибки не вызывают, и в этом отношении они достаточно безопасны. В этой статье мы попробуем разобраться в чем разница между ссылкой и указателей, когда оправдано использование указателей и как написать безопасный код с использованием указателей.
В вышеприведённом примере хорошо видно что указатель класса С_С ссылается на область памяти выделенную в классе С_А.
Так что указатели в mql5 всё таки есть, хотя программист и лишён доступа к памяти непосредственно.
Это понятно. Дело строго говоря не в указателях. Просто если передавать между программами (через события) массивы, то сразу встаёт вопрос, что именно передавать, копию массива или ссылку (указатель) на тот-же экземпляр?
Если копию - будет долго и неэкономно по памяти, если указатель, то встают проблемы синхронизации использования и ответственности потоков за разделяемую память.
Вот передали вы из одного (1) советника в другой (2) указатель на массив, второй советник его писать имеет право или только читать?
Кто отвечает за валидность указателя, если первый (1) советник вдруг закончил работу (а память распределял он)?
И т.д. и т.п.
Другими словами нужен механизм доступа к разделемой памяти, который очень чётко отличается от обычного, например тем, что в нём реализован учёт ссылок на память, и автоматизирована сборка мусора после обнуления счётчика ссылок. В принципе прецедент есть - примерно так учитываются ссылки на индикаторы.
Другой вариант реализации - глобальные переменные. Там тоже время жизни чётко оговорено правилами - либо текущая сессия, либо месяц, либо пока не будет явно удалена.
А в плане запроса к разработчикам "давайте уже что-то делать, нужен нормальный совместный доступ к массивам" - я горячо поддерживаю. Да, доступ к "соседям" нужен. Да, очень нужен. Да, желательно решать на уровне mql...
Массив - это всё-таки совокупность однотипных данных. Может, сразу замахнуться на структуры?
Yedelkin: Массив - это всё-таки совокупность однотипных данных. Может, сразу замахнуться на структуры?
На самом деле в байтовый массив (char) можно что угодно записать и, соответственно прочитать. В том числе любые структуры. Если непонятно как это сделать, возьмите как домашнюю задачку и постарайтесь решить самостоятельно. Все ответы есть в документации, только нужно правильно сложить пасьянс. :)
Насчёт объектов с виртуальными методами ситуация может быть чуть
сложнее, но тоже решаемо, особенно если разработчики чуть помогут. // Не вижу причин не помочь.
Поэтому, не суть на что замахиваться. Будут массивы - будут и структуры и какава с чаем.
Я читал. Спасибо что напомнил, сейчас сижу перечитываю. Возможно буду этот механизм юзать (только модифицирую слегка).
Что до "фицияльного" внедрения этой фишки в mql5 - сильно сомневаюсь. Здесь используется работа с указателями, которых в mql нет и не будет (мой прогноз).
Ибо управляемый доступ к памяти, является одной из основопологающих концепций mql-программирования с позиций МетаКвотов (Ренат, поправьте, если неправ). И то, что они лояльно относятся к подобному хакерству (хотя и достаточно интеллегентному), вовсе не означает, что они будут внедрять эти же механизмы в "фицияльный" mql. Мне кажется, даже "хорошо обёрнутая" реализация подобного механизма, повлечёт за собой как минимум декларирование какого-то нового механизма разделения памяти, со своими mql-правилами доступа (включая набор соответствующих ограничений). Хотя это и возможно. Почему бы и нет.
А в плане запроса к разработчикам "давайте уже что-то делать, нужен нормальный совместный доступ к массивам" - я горячо поддерживаю. Да, доступ к "соседям" нужен. Да, очень нужен. Да, желательно решать на уровне mql...
Указатели есть но они обёрнуты чтоб отстранить программиста от прямого доступа к данным.
Если применить тот же механизм оборачивания то и передачу указателя через событие можно будет точно так же закамуфлировать.
Похожий механизм кстати уже реализован при работе с классами.
В вышеприведённом примере хорошо видно что указатель класса С_С ссылается на область памяти выделенную в классе С_А.
Так что указатели в mql5 всё таки есть, хотя программист и лишён доступа к памяти непосредственно.
В вышеприведённом примере хорошо видно что указатель класса С_С ссылается на область памяти выделенную в классе С_А.
Так что указатели в mql5 всё таки есть, хотя программист и лишён доступа к памяти непосредственно.
Это понятно. Дело строго говоря не в указателях. Просто если передавать между программами (через события) массивы, то сразу встаёт вопрос, что именно передавать, копию массива или ссылку (указатель) на тот-же экземпляр?
Если копию - будет долго и неэкономно по памяти, если указатель, то встают проблемы синхронизации использования и ответственности потоков за разделяемую память.
Вот передали вы из одного (1) советника в другой (2) указатель на массив, второй советник его писать имеет право или только читать?
Кто отвечает за валидность указателя, если первый (1) советник вдруг закончил работу (а память распределял он)?
И т.д. и т.п.
Другими словами нужен механизм доступа к разделемой памяти, который очень чётко отличается от обычного, например тем, что в нём реализован учёт ссылок на память, и автоматизирована сборка мусора после обнуления счётчика ссылок. В принципе прецедент есть - примерно так учитываются ссылки на индикаторы.
Другой вариант реализации - глобальные переменные. Там тоже время жизни чётко оговорено правилами - либо текущая сессия, либо месяц, либо пока не будет явно удалена.
А в плане запроса к разработчикам "давайте уже что-то делать, нужен нормальный совместный доступ к массивам" - я горячо поддерживаю. Да, доступ к "соседям" нужен. Да, очень нужен. Да, желательно решать на уровне mql...
Массив - это всё-таки совокупность однотипных данных. Может, сразу замахнуться на структуры?
На самом деле в байтовый массив (char) можно что угодно записать и, соответственно прочитать. В том числе любые структуры. Если непонятно как это сделать, возьмите как домашнюю задачку и постарайтесь решить самостоятельно. Все ответы есть в документации, только нужно правильно сложить пасьянс. :)
Насчёт объектов с виртуальными методами ситуация может быть чуть сложнее, но тоже решаемо, особенно если разработчики чуть помогут. // Не вижу причин не помочь.
Поэтому, не суть на что замахиваться. Будут массивы - будут и структуры и какава с чаем.