Последовательность выполнение Init() и DeInit() - страница 12
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну всё, пошли причитания...
Вы просите как раз того, чего нет в обычных десктопных приложениях.
Чего-чего нет в приложениях? Синхронизации? )))
Если бы разработчики не делали всех этих фишек которые есть уже "из коробки", то писатели программ на MQL встречались бы постоянно со всем прелестями десктопных разработок, будь то проблемы безопасности и скорости выполнения.
1. Чего-чего нет в приложениях? Синхронизации? )))
2.Какие-то околонаучные рассуждения пошли, без фактов. В МТ4 индикаторы прекрасно оперируют последовательными OnInit() и DeInit(). При этом есть некоторый недостаток - работа всех индикаторов в одном потоке. Решается правильным написанием индикатора, что также требуется в МТ5. Хотя в МТ5 от этого далеко не ушли - все равно индикаторы одного чарта продолжают работать в одном потоке.1. О какой синхронизации говорите?!
2. В МТ4 в рамках выполнения кода индикатора сначала выполняется инит а потом деинит, что ещё Вам нужно?! Так же и в МТ5.
Уже несколько человек попросили привести конкретный пример задачи, выполнить которую проблематично в рамках парадигмы исполнения индикаторов в МТ5. Пример будет или нет, четкий, не высосаный из пальца?
1. О какой синхронизации говорите?!
О межпоточной. Пока один поток не завершен (тот, которому отдана команда на завершение), другой не запускается. Или же, если все это происходит в одном потоке, то еще проще: завершаем выполнение всех программ, связанных со "старым" ТФ и только после этого запускаем программы на "новом" ТФ.
2. В МТ4 в рамках выполнения кода индикатора сначала выполняется инит а потом деинит, что ещё Вам нужно?! Так же и в МТ5.
Верно. В МТ4 все именно так. Но вот в МТ5 - не так. Об этом и тема.
Уже несколько человек попросили привести конкретный пример задачи, выполнить которую проблематично в рамках парадигмы исполнения индикаторов в МТ5. Пример будет или нет, четкий, не высосаный из пальца?
Правильно, не должны. Ну вот запускаете к примеру Total Commander. Зачем требовать у Microsoft, что бы Windows позаботилась о "правильной" последовательности выгрузки/закрузки копий TC в оп.память? Разве это забота OS?
Забота OS что бы TC не мешал другим TC, а уж что они там в оп.памяти делают, файлами обмениваются или ещё чем то поинтимнее - это их, программ, дело.
"Я так думаю!" (с) Мимино, 1977г.
При чем тут Total Commander? Он то как раз - достаточно низкоуровневая утилита в том смысле, что оперирует ресурсами системы напрямую. В случае же программы MQL задача платформы МТ максимально освободить прикладного программиста от системных заморочек вроде синхронизации - это платформа может эффективнее и одним махом предоставить сама для всех. MQL программисты должны думать об анализе котировок и торговых стратегиях. В этом назначение МТ.
При чем тут обмен файлами и данными? Рассматривайте логику работы в контексте MQL программы. Речь сейчас о том, что она ничем обмениваться не собирается, а лишь пытается использовать события OnInit/OnDeinit по их прямому назначению - правильно стартовать из какого-то состояния, и правильно себя завершить с сохранением состояния. Если они для этого непригодны, то, как уже было отмечено - для чего они? Судя по доводам защитников - для того чтобы внутри пытаться плясать с бубном и выяснять, какие другие копии выполнялись до и после, и с какого таймфрейма и на какой переключились? Это как раз получается обратный эффект тому, что MQ хотела достичь - чтобы одна копия ничего не знала о другой.
Для того, что одна копия ничего не знала и не была вынуждена выяснять, и при этом работала без побочных эффектов, ядро должно знать о всех копиях - и о тех которые завершаются, и о тех, которые стартуют, - и предоставлять для них graceful обработку событий init/deinit в стандартной метафоре очереди. Терминал и так отслеживает все копии, и использует очередь событий, но почему-то init/deinit нарушают логику событий.
Для того, что одна копия ничего не знала и не была вынуждена выяснять, и при этом работала без побочных эффектов, ядро должно знать о всех копиях - и о тех которые завершаются, и о тех, которые стартуют, - и предоставлять для них graceful обработку событий init/deinit в стандартной метафоре очереди. Терминал и так отслеживает все копии, и использует очередь событий, но почему-то init/deinit нарушают логику событий.
Какая проблема хранить период в гл. переменной?
Зачем может понадобиться передавать массив данных между последовательными запусками индикатора на разных ТФ?
Андрей, ну не люблю я глобальные переменные терминала. Экспериментировал я с ними (правда давно) и очень меня разочаровала их скорость и сложности синхронизации. Чтобы не быть голословным попробую написать пример (чуть позже), демонтрирующий их скорость. Возможно уже что-то изменилось и я ошибаюсь. Но еще не нравиться мне в глобальных переменных это то, что они живут своей отдельной жизнью и они абсолютно public. Каждый может их посмотреть нажав F3 и ручками еще и удалить. Когда их несколько штук, еще полбеды, но если каждый начнет их использовать, у меня лично начинается ощущение бардака на столе.
На счет передачи массивов. Да согласен, это нужно не часто. Но вот, например, конкретный пример - мой индикатор . Его внутренняя работа не зависит от выбранного ТФ, т.к. при инициализации он закачивает все ТФ (почти все) и создает свой общий массив (нечто вроде логарифмического массива котировок) и еще происходит достаточно объемные вычисления еще несколько индексных массивов на основе его. Каждый раз при смене ТФ делать одну и ту же объемную работу совсем нерационально, будут торможения при переключении ТФ. У меня еще есть в моей голове алгоритмы по распознанию образов, которые я буду реализовывать, так там инициализационные вычисления могут достигать нескольких секунд, и хотелось бы чтобы это происходило только один раз и забыть об этом.
Для того, что одна копия ничего не знала и не была вынуждена выяснять, и при этом работала без побочных эффектов, ядро должно знать о всех копиях - и о тех которые завершаются, и о тех, которые стартуют, - и предоставлять для них graceful обработку событий init/deinit в стандартной метафоре очереди. Терминал и так отслеживает все копии, и использует очередь событий, но почему-то init/deinit нарушают логику событий.
И вот теперь представьте себе, что не существует одной единой очереди событий, а существует очередь для каждого символа-периода. Сколько символов-периодов, столько и очередей.
Теперь предложите порядок обработки очередей.
И вот теперь представьте себе, что не существует одной единой очереди событий, а существует очередь для каждого символа-периода. Сколько символов-периодов, столько и очередей.
Теперь предложите порядок обработки очередей.
1. О межпоточной. Пока один поток не завершен (тот, которому отдана команда на завершение), другой не запускается. Или же, если все это происходит в одном потоке, то еще проще: завершаем выполнение всех программ, связанных со "старым" ТФ и только после этого запускаем программы на "новом" ТФ.
2. Верно. В МТ4 все именно так. Но вот в МТ5 - не так. Об этом и тема.
3. Еще позавчера навскидку привел три примера. Вы их не видите?1. Это Ваши хотелки. Но Вы же говорили, что хотите так, как работают десктопные приложения, так вот, так как хотите Вы дестопные приложения не работают.
2. Не выдумывайте небылиц. И в МТ4 и в МТ5 последовательность выполнения онинит и ондеинит одинакова. Нет такого, что бы программа стартовала с деинит.
3. Ок, давайте разбирать примеры:
1) Делать нужно так, как я писал ранее: накопленную базу данных нужно периодически сохранять в файл или другое хранилище, проблем нет - открыли файл, записали, закрыли. Делать это нужно каждый раз при обновлении этих данных или периодически, а не в инит и деинит. (Вы же сохраняете работу периодически когда пишете программу, пишете статью). А от сбоя записи в файл невозможно застраховаться, иногда для подстраховки в критически важных ситуациях поступают так: обновлённую инфу пишут в новый файл, после успешной записи удаляют старый, а новому меняют имя как было у старого.
2) Тоже уже объяснял. Каждый индикатор должен работать со своими граф объектами. Естественно нужно делать проверку на существование уже объектов, и если уже существуют то прибавлять к имени 1.
3) Ну вот, сами написали уже что решаема.
И это не проблемы вообще. Это нормальная работа программ - создание уникальных объектов, периодическое сохранение накопленной информации, подчищение за собой после завершения.
1. Это Ваши хотелки. Но Вы же говорили, что хотите так, как работают десктопные приложения, так вот, так как хотите Вы дестопные приложения не работают.
Что Вы назваете десктопными приложениями? Такое ощущение, что МТ5 - не десктопное приложение...
2. Не выдумывайте небылиц. И в МТ4 и в МТ5 последовательность выполнения онинит и ондеинит одинакова. Нет такого, что бы программа стартовала с деинит.
Это не я выдумываю. Это - тема текущей ветки. Речь о том, что в МТ5 оказывается может сначала выполниться Init того индикатора, у которого еще не выполнен DeInit. Как раз есть. Разве тему не прочитали?
3. Ок, давайте разбирать примеры:
1) Делать нужно так, как я писал ранее: накопленную базу данных нужно периодически сохранять в файл или другое хранилище, проблем нет - открыли файл, записали, закрыли. Делать это нужно каждый раз при обновлении этих данных или периодически, а не в инит и деинит. (Вы же сохраняете работу периодически когда пишете программу, пишете статью). А от сбоя записи в файл невозможно застраховаться, иногда для подстраховки в критически важных ситуациях поступают так: обновлённую инфу пишут в новый файл, после успешной записи удаляют старый, а новому меняют имя как было у старого.
Попробуйте обновлять один и тот же файл несколько раз в секунду и поделитесь ощущениями.
2) Тоже уже объяснял. Каждый индикатор должен работать со своими граф объектами. Естественно нужно делать проверку на существование уже объектов, и если уже существуют то прибавлять к имени 1.
Причем тут прибавление к имени 1? Речь о том, что одновременно на экране существуют графические объекты от одного и того же индикатора, но разных его копий. Технически нет никакого конфликта. Конфликт будет наблюдаться у пользователя, который видит чехарду на экране до тех пор, пока не удалится старая копия.
3) Ну вот, сами написали уже что решаема.
И это не проблемы вообще. Это нормальная работа программ - создание уникальных объектов, периодическое сохранение накопленной информации, подчищение за собой после завершения.