Интервью со Станиславом Стариковым: особенности нового MQL5 - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Направление продолжения зависит от позиции, от отношения, от важности...
В любом случае, давайте дождемся первой публичной версии MQL5.
а будет ли вообще как-нибудь улучшен макропроцессор?
ну чтоб полноценные #define задавать..
ну чтоб хотябы дефайном задать какой-либо вызов функции...
Направление продолжения зависит от позиции, от отношения, от важности...
В любом случае, давайте дождемся первой публичной версии MQL5.
тут скорее соглашусь ... надежность и предсказуемость лучше функционала.
то что есть в MQL4 может не хватать порой... очень много -чуть ли не все - можно решить через DLL
в MQL5 как в языке - хотелось бы видеть в первую очередь - всю мощь ОБЪЕКТОВ, структур...
препроцессор хорошо бы расширить от базовых функций которые в MQL4 - без ущербности к функционалуа будет ли вообще как-нибудь улучшен макропроцессор?
ну чтоб полноценные #define задавать..
ну чтоб хотябы дефайном задать какой-либо вызов функции...
Во всех современных языках типа C#, Java, а так же в делфи от дефайнов отказались, а вы хотите чтобы это было в MQL5.
Эти дефайны - сила привычки или любовь в макрокомандам ввиде больших букв?
Согласен с разрабочиками что не стоит засорять язык #define. Так же стоит всё же оставить возможность написания кода вне класса (что не возможно в Java)
А просто написать набор функций в том числе и стандартные init(), start(), deinit() а в них уже можно просто создавать объекты классов библиотек MQL5, которые будут, я полагаю, вместо просто набора функций.
Иногда стратегия не сложная и класс вообще не нужен.
Меня раздражало вот в Java такая манера написания кода. Я так условно приведу пример (непомню как там точно буфферизированное чтение файла)
BufferedReader bufferedReader = new BufferedReader(new FileReader(new StreamReader("FileName.txt")))
То есть на каждое свойство новый объект и память по него выделяется. И так же у них организованно в Свинге и других библиотеках.
Проще вот так сделать. Создаёшь класс с параметрами
FileReader fileReader = new FileReader(isBuffered, "FileName.txt");
fileReader.setPath("C:\\");
Вообщем, моё мнение, в организации работы с классами и их полями лучше смотреть в сторону Delphi и их VCL чем в Java или С#
Ещё бы очень хотелось прямую индексацию массивов тайм серий по умолчанию. То есть самый первый бар в истории - нулевой а последний формирующийся был бы
Bars - 1
Так как-то логичнее и проще для восприятия.
Ещё бы очень хотелось прямую индексацию массивов тайм серий по умолчанию. То есть самый первый бар в истории - нулевой а последний формирующийся был бы
Bars - 1
Так как-то логичнее и проще для восприятия.
По умолчанию такое вряд ли будет. В этом случае всю массу кастомных индикаторов придётся переписывать. Можно будет установить режим индексации при помощи функции.
Ещё бы очень хотелось прямую индексацию массивов тайм серий по умолчанию. То есть самый первый бар в истории - нулевой а последний формирующийся был бы
Bars - 1
Так как-то логичнее и проще для восприятия.
По умолчанию такое вряд ли будет. В этом случае всю массу кастомных индикаторов придётся переписывать. Можно будет установить режим индексации при помощи функции.
Ой, нет.
Не нужно бы. Это не тот случай. Расколете программистов на 2 лагеря. Начнётся свара. На руку конкурентам..
Пусть экзотики сами себе напишут что угодно. А провоцировать не стоит.
Исходно можно было бы и так и эдак. Всё равно как. А теперь лучше бы придерживаться единообразия.
Ещё бы очень хотелось прямую индексацию массивов тайм серий по умолчанию. То есть самый первый бар в истории - нулевой а последний формирующийся был бы
Bars - 1
Так как-то логичнее и проще для восприятия.
По умолчанию такое вряд ли будет. В этом случае всю массу кастомных индикаторов придётся переписывать. Можно будет установить режим индексации при помощи функции.
Ой, нет.
Не нужно бы. Это не тот случай. Расколете программистов на 2 лагеря. Начнётся свара. На руку конкурентам..
Пусть экзотики сами себе напишут что угодно. А провоцировать не стоит.
Исходно можно было бы и так и эдак. Всё равно как. А теперь лучше бы придерживаться единообразия.
+1 Кому надо - пусть сам переворачивает, не так сложно
Ну убидили, впринципе я конечно сам могу поставить прямое индексирование массивов(такая же функция сделать прямую индексацию уже есть). Такую возможность не сразу заметил и уже несколько индикаторов написал с обратным индексированием.
И ещё хочеться побольше таймфреймов загружаемых типа M3 или H8. Думаю добавить количество таймфреймов до D1 доступных совсем не сложно.
Модуль расчёта таймфремов любых на серверной части системы уже ведь есть.
Либо возможность пересчитать в нужный таймфрейм уже на клиенте, но так чтобы эти таймфремы можно было свободно использовать на чарте и при загрузке минуток чтобы этот custom bars пересчитывались на лету и отрисовывались на чарте и в советнике прикреплённому к этому чарту были доступны эти таймсерии. А то так ограничения какие то и нет дополнительных возможностей для экспериментов и поиска стратегий мультипериодных.
Очень полезное интервью, увидел его только сейчас.
Порадовало расширение возможностей разработки. Если я верно понял фразу "как в .Net преобразование байт кода в нативный x86 код", появился just-in-time compiler. Порадовало появление проектов с раздельныим файлами. И мелькнувший screenshot среды разработки MQL5 с треугольной кнопкой отладчика - это главный бонус, на мой взгляд. Пока неизвестен вопрос совместимости/переноса проектов MQL4 --> MQL5. Хотелось бы получить беспроблемную портацию.
В любом случае спасибо Metaqoutes. Ждём.