Интересная тема для многих: что будет нового в MetaTrader 4 и MQL4 - большие изменения на подходе - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Раз коснулись маркета, хотелось бы услышать мнения по одному вопросу...
По философии MQL5 индикаторы должны считать, советники торговать.
Но в маркете продаются готовые решения, как говориться всё в одном.
Может доработать компилятор чтоб индикаторы хранились в советниках как ресурсы?
А то приходится переносить код индикатора в советник, где у него нет должного окружения. Опять же при схеме "индикатор от индикатора" перенос кода в советник это уже целая эпопея.
поддерживаю,
мне кажется для маркета сейчас было бы полезным добавить еще вкладку - ФАЙЛЫ, куда можно складывать например сеты, инструкции и так далее,
хотя - вкладка Обсуждение дает такую возможность, но все равно не то.
Может доработать компилятор чтоб индикаторы хранились в советниках как ресурсы?
А то приходится переносить код индикатора в советник, где у него нет должного окружения. Опять же при схеме "индикатор от индикатора" перенос кода в советник это уже целая эпопея.
Смотрите новость MetaTrader 5 Client Terminal build 730 от 24 ноября 2012 года
8. MQL5: Добавлена поддержка хранения индикаторов в ресурсах EX5. При этом индикаторы в ресурсах не смогут работать со своими собственными ресурсами.
Смотрите новость MetaTrader 5 Client Terminal build 730 от 24 ноября 2012 года
Именно так я и поступаю. И классы, умеющие передавать советнику кастомную историю (вместо реальной с сервера) у меня уже написаны. Но для полной реализации задумки советник не должен использовать функции терминала напрямую. Скажем, ту же OrderSend(). Он должен работать только через некую "обертку", в роли которой замечательно подходит Стандартная Библиотека. Пишем производные классы, подсовываем советнику, и - вуаля - он работает теперь на исторических данных. Если же советник будет использовать функции терминала напрямую - никак ему историю и не подсунешь.
Ну, видимо, сказывается моя долгая работа с библиотекой MFC, которой я был очень доволен, и с которой нахожу массу паралелей. Уверен, что разработчики Стандартной Библиотеки также неплохо знакомы с MFC.
Главный плюс Стандартной Библиотеки - хорошая поддержка идеологии ООП, которая, как раз и позволяет при необходимости передавать советнику кастомную историю так, что советник будет вполне нормально работать безо всяких переделок.
А можно поинтересоваться, чем вам Стандартная Библиотека не нравится (ну, кроме очевидного минуса - "лень изучать") ?
Вот как раз такого минуса нет, я знаю СБ отлично, и это знание даёт понимание насколько всё громоздко и неэффективно.
Вместо того чтоб отправить приказ начинается бабка за дедку, дедка за репку.
Но главный минус (по Trade) контроль исполнения напрочь отсутствует. Бумкнули ордер в сервер и хоть трава не расти. Зато обернули Send 10 способами, типа на все случаи жизни, а случаев оказалось 100.
По идеологии: наследование больше чем на 2 поколения считаю ошибкой, дальше теряется как понимание так и гибкость.
Большинство классов (вы правы) не изобретены а тупо перебиты с MFC, ну это скорее не минус, зачем изобретать велосипеды.
Но главным минусом считаю что не возможно на неё полагаться, напишешь что то на ней а её доработают :)
Я писал и с СБ и без. Без получается быстрее и прозрачнее. Слишком она универсальна, поэтому неповоротлива на виражах.
В Дельфи например там есть понятие проект, подразумевающий совместную компиляцию. А разделение программ на 3 типа оно немного сомнительно в общем, потому как компилятор по идее может сам определится, что делает программа, но раз уж так пошло, что индикаторы торгуют только насильно, а для советника надо внедрять код внутрь, то остается только надеяться, что сердце разработчиков когда-нибудь растает и они позволят делать проекты).
поддерживаю,
мне кажется для маркета сейчас было бы полезным добавить еще вкладку - ФАЙЛЫ, куда можно складывать например сеты, инструкции и так далее,
хотя - вкладка Обсуждение дает такую возможность, но все равно не то.
Смотрите новость MetaTrader 5 Client Terminal build 730 от 24 ноября 2012 года
Супер, как это я пропустил, аааа это предновогодние билды.
Означает ли перечёркивание в вашем посте, что уже могут?
Вот как раз такого минуса нет, я знаю СБ отлично, и это знание даёт понимание насколько всё громоздко и неэффективно.
Спасибо за развернутый ответ. По всем вашим высказываниям у меня нет категорических возражений. Так... некоторые замечания...
Вместо того чтоб отправить приказ начинается бабка за дедку, дедка за репку.
Но ведь именно это и дает гибкость системы, и именно за счет этого мы и можем передавать советнику кастомную историю и эмуляцию сервера. Если бы приказы отправлялись прямо через OrderSend() - пришлось бы эту самую "бабка за дедку, дедка за репку" - писать самим... Непонятно, что лучше...
Но главный минус (по Trade) контроль исполнения напрочь отсутствует. Бумкнули ордер в сервер и хоть трава не расти. Зато обернули Send 10 способами, типа на все случаи жизни, а случаев оказалось 100.
Тут у меня еще недостаточно опыта. Пока могу лишь теоретизировать. Анализ кодов возврата - я провожу пока сам, но опыта работы крайне мало. Согласен, что контроля исполнения в самой СБ недостаточно.
По идеологии: наследование больше чем на 2 поколения считаю ошибкой, дальше теряется как понимание так и гибкость.
Да, действительно, слишком глубокое наследование весьма неблагоприятно влияет на понимание. Но насчет гибкости - мне сложно согласиться. У меня куча случаев наследования на 4-5 поколений, и, вроде как никаких проблем это не вызывает. Но, могу согласиться, что это у меня так, для других, возможно, такая глубина наследования сильно мешает.
Но главным минусом считаю что не возможно на неё полагаться, напишешь что то на ней а её доработают :)
Вот тут - да, полностью согласен.
Я писал и с СБ и без. Без получается быстрее и прозрачнее. Слишком она универсальна, поэтому неповоротлива на виражах.
Мне СБ понравилась именно возможностью создания шаблона ТС, и в дальнейшем - подключения к нему лишь классов-объектов, описывающих входы, сопровождение и выходы. Боюсь, без СБ такая идеология приведет к созданию той же, только Собственной СБ.
Насчет "быстрее и прозрачнее" - мне кажется, что такая идеология хороша, когда у нас любая ТС рассматривается, как единое целое. Однако, мне кажется, что это - серьезная ошибка алготрейдинга. ТС должна рассматриваться исключительно, как комплекс "кубиков" - набор генераторов входа, определитель входных ТП-СЛ, определитель входного лота, контроллер трейлинга и так далее... Такая идеология позволяет очень быстро получать сотни различных вариантов ТС там, где "быстрее и прозрачнее" мы имеем только несколько.
Скажем, написав без шаблона пять различных ТС - для написания шестой нам опять надо опять все писать заново, пусть даже используя куски из этих пяти систем. Написав же шаблон - мы эти пять систем будем в него забивать только по частям, и в результате будем иметь до пяти генераторов входа, фильтров входа, определителей ТП-СЛ, и так далее. Комбинируя их - мы легко получаем сотню ТС, из которых можно выбрать наиболее устойчивые и прибыльные.
Поэтому, на мой взгляд, неповоротливость СБ - действительно, "палка о двух концах", и применение ее или неприменение - должно решаться в каждом случае индивидуально.
Супер, как это я пропустил, аааа это предновогодние билды.
Означает ли перечёркивание в вашем посте, что уже могут?
Супер, как это я пропустил, аааа это предновогодние билды.
Вот тут это обсуждалось: https://www.mql5.com/ru/forum/3409#comment_408123