init, main... on_order_closed - было бы полезно
В этом случае это была бы уже событийная модель обработки, а этого даже близко не наблюдается в текущей реализации МТ.
Согласен, что это было бы очень хорошо, это соответствовало бы современной, так сказать, парадигме разработке ПО, особенно, если еще добавить ООП, которого тоже даже близко нет в МТ, несмотря на давнюю статью уважаемого Роша.
Но думаю, что разработчики не будут этого делать и в следующей версии МТ :(
Согласен, что это было бы очень хорошо, это соответствовало бы современной, так сказать, парадигме разработке ПО, особенно, если еще добавить ООП, которого тоже даже близко нет в МТ, несмотря на давнюю статью уважаемого Роша.
Но думаю, что разработчики не будут этого делать и в следующей версии МТ :(
На самом деле, у нас - событийная модель обработки. Событие - приход тика. Все остальные предполагаемые события - вторичны. Не будет события on order closed без прихода нового тика.
Можно, конечно, вешать по отдельному эксперту на каждое событие. Но поверьте, тогда кашу в терминале можно будет сделать так же просто, как два байта переслать. А расхлёбывать эту кашу придётся нам, и очень часто.
Также не забывайте, что Вы приводите пример событийной модели, в которой все события происходят от одного источника - интерфейсного потока. То есть, синхронны. У нас этих источников может быть больше, как минимум - интерфейсный поток и поток подкачки. Такую событийную модель разруливать гораздо сложнее.
Можно, конечно, вешать по отдельному эксперту на каждое событие. Но поверьте, тогда кашу в терминале можно будет сделать так же просто, как два байта переслать. А расхлёбывать эту кашу придётся нам, и очень часто.
Также не забывайте, что Вы приводите пример событийной модели, в которой все события происходят от одного источника - интерфейсного потока. То есть, синхронны. У нас этих источников может быть больше, как минимум - интерфейсный поток и поток подкачки. Такую событийную модель разруливать гораздо сложнее.
Нет, на отдельных экспертов (с отдельными потоками, хехе) я и не замахивался )). Да и ООП, кажется мне, может стать слишком тяжеловесным подходом для mql (статью Rosh-а не видел, буду признателен, если кинете ссылку). При желании все ООП можно реализовать внешними модулями, так что здесь у меня особых желаний и потребностей нет.
Я имел в виду, скорее, некую "псевдособытийность" с заранее заданными правилами. Вот как сейчас есть "процедура инит, выполняется в начале работы", так и будет существовать в документации раздельчик "вы можете реализовать процедуру онклозе, которая выполняется при приходе очередного тика перед запуском start, в том случае, если за прошедшее время был закрыт ордер. В случае нескольких закрытых ордеров процедура выполняется поочередно для каждого ордера в той последовательности, в которой ордера были закрыты".
Фактически, то же самое, что сейчас приходится делать при необходимости onclose отследить - ведя массив открытых ордеров, сверяя его с реальным - и по результатам расхождения вызывая те же пользовательские on_open, on_close - но со спрятанными неаппетитными кишками.
Ведь подобие init тоже можно реализовать в start, заведя булевскую переменную first_run и выделив в start отдельный блок работы "при первом проходе". Но куда удобней, когда init лежит отдельно. Так же и с onclose.
Т.е. это некое опциональное расширение, а не смена парадигмы.
А вот про "интерфейсный поток" и "поток подкачки" можно чуть подробней? крайне любопытно. Подкачка имеется в виду - исторических тиков? А как она взаимодействует с экспертами?
Я имел в виду, скорее, некую "псевдособытийность" с заранее заданными правилами. Вот как сейчас есть "процедура инит, выполняется в начале работы", так и будет существовать в документации раздельчик "вы можете реализовать процедуру онклозе, которая выполняется при приходе очередного тика перед запуском start, в том случае, если за прошедшее время был закрыт ордер. В случае нескольких закрытых ордеров процедура выполняется поочередно для каждого ордера в той последовательности, в которой ордера были закрыты".
Фактически, то же самое, что сейчас приходится делать при необходимости onclose отследить - ведя массив открытых ордеров, сверяя его с реальным - и по результатам расхождения вызывая те же пользовательские on_open, on_close - но со спрятанными неаппетитными кишками.
Ведь подобие init тоже можно реализовать в start, заведя булевскую переменную first_run и выделив в start отдельный блок работы "при первом проходе". Но куда удобней, когда init лежит отдельно. Так же и с onclose.
Т.е. это некое опциональное расширение, а не смена парадигмы.
А вот про "интерфейсный поток" и "поток подкачки" можно чуть подробней? крайне любопытно. Подкачка имеется в виду - исторических тиков? А как она взаимодействует с экспертами?
Сами статьи пока доступны по временному адресу - http://old.alpari.org/ru/experts/articles/
Возможно, имеется ввиду одна из начальных статей, где упоминается ООП .
Возможно, имеется ввиду одна из начальных статей, где упоминается ООП .
Поток подкачки - это отдельный поток для связи клиентского терминала с торговым сервером. Проще говоря, это бесконечный цикл по приёму от сервера различных данных, в первую очередь, тиков, новостей, списков открытых и закрытых позиций и т.п. Как только приходят те или иные данные, они соответствующим образом разруливаются и в основной (интерфейсный) поток клиентского терминала посылается соответствующее сообщение.
Если это был новый тик, то клиентский терминал перерисовывает соответствующий график, пересчитывает индикаторы на этом графике и запускает эксперта, прикреплённого к этому графику.
Аналогичный поток подкачки был в МТ3. Вы можете посмотреть 2-й пример, поставляемый с MT3 API.
Если это был новый тик, то клиентский терминал перерисовывает соответствующий график, пересчитывает индикаторы на этом графике и запускает эксперта, прикреплённого к этому графику.
Аналогичный поток подкачки был в МТ3. Вы можете посмотреть 2-й пример, поставляемый с MT3 API.
Событие - приход тика. Все остальные предполагаемые события - вторичны. Не будет события on order closed без прихода нового тика.
Разве ордера закрываются терминалом? я думал, сервер решает какой ордер закрывать и присылает терминалу сигнал , что ордер изменен. Связь с приходом тика тут косвенная.
Что касается целесообразности доступа к событию изменения ордера сервером, тут с вами не соглашусь. Да, полноценная событийная модель гораздо сложнее вашей, но в данном случае я не вижу где может быть путаница. (З.Ы. Если советник не зацикленый :) )
Сервер закрывает ордер только после изменения цены. В этом - связь.
Вот ссылка на статьи уважаемого Роша, где упоминается "Объектное представление в MetaTrader4", но ссылка сама битая :(
"MQL4: Обзор статей Rosh'а: эксперты в MetaTrader 4"
Здесь ключевое слово "у нас". У тех же, кто пишет эксперты, ее нет вообще. Я имею в виду, как собственно и все, кто говорит о событийной парадигме программирования, возможность реагирования программы на различные события. Например, OnCloseOrder(intNumOrder, strSymbol), OnOpenOrder(intNumOrder, strSymbol), OnPressButton(intCodeButton), OnTick(...) и т.д.
Никакой каши, наоборот, четко видно, когда и что будет отрабатываться. Вот сейчас как раз больше предпосылок для создания каши, когда запускается весь огромный, несколько сотен строк (как кто напишет:), эксперт. В случае же событий отработается только нужный для обработки именно этого события кусок кода. Разве это не более целесообразно?
Мне это видится по другому. Интерфейсных потоков больше, чем один. Например, один - поступление котировок, другой - поступление событий от устройств ввода, например, клава или мышь. И приходят они асинхронно. Добавлю сюда же обработку исключений, что тоже является событием.
Вообще, в случае работы по событиям программист должен думать по другому, это уже совершенно другой стиль программирования, и , в отличие от Вашего, чисто линейного стиля, он более приближен к реальному миру, который нас окружает, т.к. и в обычной жизни мы действуем, в основном, в стиле реагирования на события. И именно поэтому, на мой взгляд, это стиль более прогрессивен. Возьмите современные языки программирования, там это все есть давным-давно, наряду с ООП.
Другое дело, что это требует перестройки стиля мышления программеров, что, на мой взгляд, и будет являться препятствием для внедрения такой парадигмы программирования в Ваш продукт. Ибо он создавался не для профессиональных программеров, а для торгующей публики. И, возможно, такая коренная перестройка будет лишней для дальнейшего успеха Вашей программы.
В любом случае, мне нравится Ваш продукт и хотя мне хотелось бы его дальнейшего развития в сторону ООП, я не забываю о том, что главное на рынке, это не то, какой ширины и из какого металла у тебя лопата для загребания денег, а умение в нужную сторону эту лопату разворачивать. Другими словами, более важна система, по которой ты работаешь на рынке, нежели чем инструмент, с помощью которого ты работаешь. Можно зарабатывать на рынке, торгую просто по телефону и выполняя небольшие расчеты на бумажке. Вот это и есть самое главное - система. Но это уже тема других форумов.
Прошу прощения за такой длинный пост. Что-то развезло немного с 200 грамм :)
"MQL4: Обзор статей Rosh'а: эксперты в MetaTrader 4"
На самом деле, у нас - событийная модель обработки. Событие - приход тика. Все остальные предполагаемые события - вторичны. Не будет события on order closed без прихода нового тика.
Здесь ключевое слово "у нас". У тех же, кто пишет эксперты, ее нет вообще. Я имею в виду, как собственно и все, кто говорит о событийной парадигме программирования, возможность реагирования программы на различные события. Например, OnCloseOrder(intNumOrder, strSymbol), OnOpenOrder(intNumOrder, strSymbol), OnPressButton(intCodeButton), OnTick(...) и т.д.
Можно, конечно, вешать по отдельному эксперту на каждое событие. Но поверьте, тогда кашу в терминале можно будет сделать так же просто, как два байта переслать. А расхлёбывать эту кашу придётся нам, и очень часто.
Никакой каши, наоборот, четко видно, когда и что будет отрабатываться. Вот сейчас как раз больше предпосылок для создания каши, когда запускается весь огромный, несколько сотен строк (как кто напишет:), эксперт. В случае же событий отработается только нужный для обработки именно этого события кусок кода. Разве это не более целесообразно?
Также не забывайте, что Вы приводите пример событийной модели, в которой все события происходят от одного источника - интерфейсного потока. То есть, синхронны. У нас этих источников может быть больше, как минимум - интерфейсный поток и поток подкачки. Такую событийную модель разруливать гораздо сложнее.
Мне это видится по другому. Интерфейсных потоков больше, чем один. Например, один - поступление котировок, другой - поступление событий от устройств ввода, например, клава или мышь. И приходят они асинхронно. Добавлю сюда же обработку исключений, что тоже является событием.
Вообще, в случае работы по событиям программист должен думать по другому, это уже совершенно другой стиль программирования, и , в отличие от Вашего, чисто линейного стиля, он более приближен к реальному миру, который нас окружает, т.к. и в обычной жизни мы действуем, в основном, в стиле реагирования на события. И именно поэтому, на мой взгляд, это стиль более прогрессивен. Возьмите современные языки программирования, там это все есть давным-давно, наряду с ООП.
Другое дело, что это требует перестройки стиля мышления программеров, что, на мой взгляд, и будет являться препятствием для внедрения такой парадигмы программирования в Ваш продукт. Ибо он создавался не для профессиональных программеров, а для торгующей публики. И, возможно, такая коренная перестройка будет лишней для дальнейшего успеха Вашей программы.
В любом случае, мне нравится Ваш продукт и хотя мне хотелось бы его дальнейшего развития в сторону ООП, я не забываю о том, что главное на рынке, это не то, какой ширины и из какого металла у тебя лопата для загребания денег, а умение в нужную сторону эту лопату разворачивать. Другими словами, более важна система, по которой ты работаешь на рынке, нежели чем инструмент, с помощью которого ты работаешь. Можно зарабатывать на рынке, торгую просто по телефону и выполняя небольшие расчеты на бумажке. Вот это и есть самое главное - система. Но это уже тема других форумов.
Прошу прощения за такой длинный пост. Что-то развезло немного с 200 грамм :)
Не нужно нас "агитировать за коммунизм. Мы и так - партийные".
На си++ я программирую года этак с 1992. В 1995 году приятель принёс отличную книжку Гради Буча "Объектно-ориентированный анализ и проектирование". Таскал её с собой повсюду. Однажды в трамвае меня приняли за строителя из-за названия книжки. В общем, проникся.
Я очень обрадовался, когда вышло второе издание этой книги - там уже все примеры были на си++ (в первом издании аж на 5 языках, что осложняло понимание).
Ещё одно издание у меня - настольное. Ирэ Пол (в некоторых изданиях Айра Пол) "Объектно-ориентированное программирование с использованием Си++"
Так что, идейный я. Однако здесь необходимо найти правильное соотношение между программированием и торговлей. Можно увлечься объектной ориентированностью, событийностью, обработкой исключений, переопределением функций и операторов и т.п. в ущерб торговле. "А сейчас посмотрим как это всё взлетит" (ц)
На си++ я программирую года этак с 1992. В 1995 году приятель принёс отличную книжку Гради Буча "Объектно-ориентированный анализ и проектирование". Таскал её с собой повсюду. Однажды в трамвае меня приняли за строителя из-за названия книжки. В общем, проникся.
Я очень обрадовался, когда вышло второе издание этой книги - там уже все примеры были на си++ (в первом издании аж на 5 языках, что осложняло понимание).
Ещё одно издание у меня - настольное. Ирэ Пол (в некоторых изданиях Айра Пол) "Объектно-ориентированное программирование с использованием Си++"
Так что, идейный я. Однако здесь необходимо найти правильное соотношение между программированием и торговлей. Можно увлечься объектной ориентированностью, событийностью, обработкой исключений, переопределением функций и операторов и т.п. в ущерб торговле. "А сейчас посмотрим как это всё взлетит" (ц)
Однако здесь необходимо найти правильное соотношение между программированием и торговлей. Можно увлечься объектной ориентированностью, событийностью, обработкой исключений, переопределением функций и операторов и т.п. в ущерб торговле.
да согласен я с этим, о том же и говорю, хоть и другими словами:
Другое дело, что это требует перестройки стиля мышления программеров, что, на мой взгляд, и будет являться препятствием для внедрения такой парадигмы программирования в Ваш продукт. Ибо он создавался не для профессиональных программеров, а для торгующей публики. И, возможно, такая коренная перестройка будет лишней для дальнейшего успеха Вашей программы.
Меня просто немного задело упоминание уважаемым Рошом об объектной ориентированности MQL, и то, что Вы сказали, что у Вас событийная модель обработки, имея в виду только лишь обработку прихода тика.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Разумеется, при некотором напряжении творческой мысли пишутся процедуры-эмуляторы - но не вполне элегантно.
Опять же разумеется, учитывая нынешнюю ситуацию с разработкой и дополнениями MT4 - это предлагается, скорее, в MT5, MT6 и т.п.