Ошибки, баги, вопросы - страница 2541

Новый комментарий
 
Ilyas:
Так вы же не вернули управление обратно в терминал, "зависли" в "бесконечном" цикле внутри Fn в DLL.
О каком нормальном завершении может идти речь!

Если нужно подобное поведение, то внутри Fn в DLL необходимо запустить отдельный поток с циклом, который останавливать по флагу, который выставляется в отдельной функции FnStop и при DLL_PROCESS_DETACH

То что не вернул управление обратно, это сделано для примера, это понятно что while нужно запускать в отдельном потоке, чтобы не блочить поток mql.
Но то же поведение получаю когда запускаю while в другом потоке, проблема в DLL_PROCESS_DETACH, этот идентификатор не срабатывает, для имеющегося уже флага Detach.
Да, уже писали, что нужно заводить отдельную экспортируемую функцию, и через неё управлять флагом.
Но так как показано в примере, флаг в DLL_PROCESS_DETACH не срабатывает.
По этому возможно есть ошибка в терминале, логично же, что DLL_PROCESS_DETACH должен выполнять перевод флага в другое состояние.
Цикл while получив это состояние, выходит из цикла, выполняется всё что встречается на пути и завершает саму функцию Fn()
И только после этого должна происходить выгрузка dll  !
Но этого не происходит, получается какая то ранняя выгрузка dll скрытыми механизмами терминала, по этому получаем аварийное завершение.  

 
TheXpert:

чтобы в обсуждение багов и конструкций не лезли со своими комментами некомпетентные типа тебя, федосеева и т.д.

чтобы конструкции и механизмы взятые в MQL из С++ целиком и выглядящие так же как в С++ работали так же как в С++.

это бред и ты это знаешь, но тебе ведь набросить надо.

ноешь как раз ты. про то как достали, про отдельный язык и про отдельную ветку.

открой для себя и сочувствующих отдельную ветку и ной там.

Я был о тебе лучшего мнения. Ошибся. Бывает. Ты хам и ... не умный.

 
Roman:

То что не вернул управление обратно, это сделано для примера, это понятно что while нужно запускать в отдельном потоке, чтобы не блочить поток mql.
Но то же поведение получаю когда запускаю while в другом потоке, проблема в DLL_PROCESS_DETACH, этот идентификатор не срабатывает, для имеющегося уже флага Detach.
Да, уже писали, что нужно заводить отдельную экспортируемую функцию, и через неё управлять флагом.
Но так как показано в примере, флаг в DLL_PROCESS_DETACH не срабатывает.
По этому возможно есть ошибка в терминале, логично же, что DLL_PROCESS_DETACH должен выполнять перевод флага в другое состояние.
Цикл while получив это состояние, выходит из цикла, выполняется всё что встречается на пути и завершает саму функцию Fn()
И только после этого должна происходить выгрузка dll  !
Но этого не происходит, получается какая то ранняя выгрузка dll скрытыми механизмами терминала, по этому получаем аварийное завершение.  

Дай угадаю. Если запускаешь из dll цикл в потоке терминала, то зависание, а если в отдельном потоке, которому detach() делаешь, то терминал падает с ошибкой?
 
Roman:

То что не вернул управление обратно, это сделано для примера, это понятно что while нужно запускать в отдельном потоке, чтобы не блочить поток

так приводите сразу правильный пример. и оставьте аттачи детачи в покое. управляйте созданием\удалением потоков явно сами.
 

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Ошибки, баги, вопросы

Sergey Dzyublik, 2019.05.26 15:12

К сожалению, на текущий момент возможности указателей на функции (function pointer types) в МТ4/MT5 весьма ограничены и не практичны из-за ряда дефектов:
 (не исправлено в MT5(build 2118)) "Ошибка компиляции при повторном использовании одной и той же сигнатуры функции в рамках typedef".
 (не исправлено в MT5(build 2118))  "При работе с typedef использование шаблонной функции с явной специализацией не вызывает генерацию кода этой шаблонной функции".


В виду ожидаемого внедрения пространства имен, прошу в рамках исправлений дефектов рассмотреть возможность внедрения поддержки следующего С++ подобного поведения:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (build 2118), Сколько еще можно ждать исправлений багов в работе функциональности typedef?
Какой-то бред - шаг влево от примитивного примера по использованию   typedef и все - куча багов, блокирующих дальнейшую разработку.

 
Vladimir Simakov:
Дай угадаю. Если запускаешь из dll цикл в потоке терминала, то зависание, а если в отдельном потоке, которому detach() делаешь, то терминал падает с ошибкой?

Не совсем так.
Запуск цикла работает нормально.
Проблема когда принудительно останавливаешь программу, и передаёшь флаг в цикл, чтобы он вышел из цикла и завершил работающую функцию.
Но терминал не даёт корректно выйти из цикла и завершить работающую функцию, потому что уже сработала ранняя выгрузка dll. Получаем висяк.
dll выгружается раньше, чем передаётся состояние флага, и функция Fn не завершается, ранняя выгрузка всё ломает.

В потоке терминала сделал для примера, чтоб не писать весь код, так как в блокирующем режиме проблему лучше видно.
Уже и отдельную функцию завел для флага цикла, запущенный цикл работает в другом потоке, но всё то же самое поведение.
И когда пытаюсь из не заблокированного кода mql, через функцию перевести флаг в другое состояние чтобы выйти из цикла,
терминал не ждёт завершения работающего цикла, и не даёт завершить функцию Fn где крутится цикл.
Терминал сразу производит раннюю выгрузку dll не дожидаясь когда функция Fn завершится. Вот в чём проблема.

TheXpert:
так приводите сразу правильный пример. и оставьте аттачи детачи в покое. управляйте созданием\удалением потоков явно сами.

В заблокированном режиме лучше видно проблему. По сути не важно чем изменяется состояние флага. Точкой входа или отдельной функцией.
Для блокирующего режима лучше подходит точка входа, так как управление обратно не передано, и вызвать функцию изменения флага не получиться. По этому атачи детачи для примера.
Атачи детачи оставил в покое, завёл отдельную функцию как вы посоветовали, нифига, на рабочем проекте в неблокирующем режиме, то же поведение.
Происходит ранняя выгрузка dll, работающая функция где крутится цикл while не успевает завершится, как прилетает висяк.

 
Roman:

Происходит ранняя выгрузка dll, работающая функция где крутится цикл while не успевает завершится, как прилетает висяк.

не может быть висяка в нормальной реализации

 

Кто-нибудь сталкивался со следующей проблемой с кастом-символами? В функцию CustomRatesUpdate передаются нормальные котировки, а по факту на график и в окно данных попадает нечто странное (в данном случае, в close и low значения в 100 раз меньше, чем переданные):

Также параллельно эмулируются одиночные тики с помощью CustomTicksAdd с теми же значениями цены close, что в логе (непосредственно перед CustomRatesUpdate), т.е. откуда берутся уменьшенные значения в котировках - не понятно.

UPD:

На USDCAD получил "обратную" в некотором смысле ситуацию - котировки после записи увеличиваются в 10 раз. Вот такой лог получаю:

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

Первый ArrayPrint - то, что записывалось в CustomRatesUpdate, а второй ArrayPrint - то, что прочитано с помощью CopyRates из последнего самого свежего бара сразу после записи. Во-первых, различие в последнем разряде в open, но что более важно - high и close увеличены в 10 раз.

 
Stanislav Korotky:

Кто-нибудь сталкивался со следующей проблемой с кастом-символами? В функцию CustomRatesUpdate передаются нормальные котировки, а по факту на график и в окно данных попадает нечто странное (в данном случае, в close и low значения в 100 раз меньше, чем переданные):

Также параллельно эмулируются одиночные тики с помощью CustomTicksAdd с теми же значениями цены close, что в логе (непосредственно перед CustomRatesUpdate), т.е. откуда берутся уменьшенные значения в котировках - не понятно.

Да, сталкивался, только у меня ноль не понятный проскакивал. У тебя в 100 крат проскакивает.
Делал доп проверку на ноль, не помогло, работало криво, то нормально то рисовал такие шипы.
В основном такое поведение наблюдал при первом запуске программы, и при первом запуске создавались файлы истории с несуществующей датой.
Чистил папку тиков, корректировал код, чтоб найти где же баг, надоело, пока отложил, но тоже предстоит мне ещё вернуться к этой проблеме  (( 
Проверь ещё папку кастомной истории, там могут быть файлы с несуществующей датой ))
В общем жук живёт там конкретный.

Продублируй проблему в эту ветку 
Там вроде Слава по кастомным символам заведует.
Чтобы напомнить о проблеме.
 

Говорили уже про эту ошибку? Не могу найти. Суть: при загрузке результатов оптимизации из кэш файла результаты форвардов отображаются некорректно. В значениях параметров левые цифры.

Заходишь во вкладку оптимизация. Выбираешь эксперта. Выбираешь одну из бывших оптимизаций. Бэк-тесты загружаются нормально. Форварды выдают это:



МТ5, билд последний. х64.

1...253425352536253725382539254025412542254325442545254625472548...3518
Новый комментарий
Причина обращения: