Какие планы по расширению синтаксиса языка программирования MQL5 до C++?

[Nazariy Stapyak]

Хотелось бы узнать от разработчиков перспективы становления MQL5 все более совместимым с С++:

Планируется ли добавление например typedef, inline(хотя бы для большей совместимости), оператора -> и т.п?

Как насчет условной компиляции, ссылок (&), шаблонов?

Или все же больших продвижений в этом направлении не будет с целью не усложнять синтаксис?

[Renat Fatkhullin]

Язык постоянно расширяется.

Typedef отлично заменяется struct или class (а если нужно переопределить просто тип, то это можно сделать через #define), inline автоматический(его не надо указывать), условной компиляции пока не планируем(хотя это иногда нужно для портирования кода), ссылки -> заменяются точкой, безопасные ссылки & всегда были(это контролируемый язык, поэтому ссылок на все как в С++ не будет), шаблонов пока нет.

Фактически следующий большой шаг - это внедрение шаблонов.

[Nazariy Stapyak]

 Да, все это можно заменить, но я говорю о том чтобы синтаксис был более похож, например, при переводе кода с С++ на MQL5 не нужно было удалять inline(его ведь можно просто добавить в список ключевых слов и игнорировать при компиляции), менять -> на точку, менять возврат по ссылке на возврат указателя, и т.д. 

[Renat Fatkhullin]

Inline пропускать можно, а вот подменять операторы на лету - ни в коем случае.

[Konstantin Grebenshikov]

 Не нужно будет оптимизировать Dll под специфический язык программирование, что дает возможность использовать библиотеки написанные на Net или другие . Например С++AMP или ACML (AMD Core Math Library) ,так как я думаю будущее за ними. Зачем трудиться в написание строк кода, если можно использовать оптимизированные библиотеки которые сделают половину работы.

P.s Renat посмотрите в свой профиль в раздел сообщения. 

[Renat Fatkhullin]

GKS:

 Не нужно будет оптимизировать Dll под специфический язык программирование, что дает возможность использовать библиотеки написанные на Net или другие . Например С++AMP или ACML (AMD Core Math Library) ,так как я думаю будущее за ними. Зачем трудиться в написание строк кода, если можно использовать оптимизированные библиотеки которые сделают половину работы.

А какие сейчас есть проблемы использования чужих библиотек?

В последних билдах мы вообще расширили поддержку разных типов вызовов DLL функций и учитываем массу способов декорирования имен функций. Это помогает разработчикам более просто использовать DLL. Достаточно бросить DLL файл из дерева навигации в поле редактора и автоматически получить практически полный список прототипов функций.

[Konstantin Grebenshikov]

Renat:

А какие сейчас есть проблемы использования чужих библиотек?

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

Если я правильно понимаю это всего прототипы которые нуждаются в адаптация под MQL5, а если будет реализована совместимость с С++, то будет пороше разработчикам и пользователям  . 

[[Удален]]

Тут надо понимать, что интересы трейдера и MQ кардинально различаются. MQ надо посадить на свой вариант языка как можно больше людей, чтобы таким образом стимулировать посредников(ДЦ) к покупке продукта. Поэтому полная совместимость им не нужна. Понятно, что затратив большие усилия на адаптацию алгоритмов, трейдеру сложнее будет переходить на альтернативные платформы. Поэтому, имхо, все, что не относится к исполненю торговых команд писать надо на независимых чистых языках. Т.о. можно не связывать себе руки и не тратить время в дальнейшем на переписывание кода. Ведь не секрет, что когда трейдер вырастает, он может уйти к серьезным брокерам, мнгие из которых используют только собственное ПО по соображениям безопасности. Тут библиотеки на независимых языках могут и выручить. Или появится MT 6 (MQ ведь нужны будут новые продажи в будущем), и опять 25 - переписывай все.

[John]

-Alexey-:
Тут надо понимать, что интересы трейдера и MQ кардинально различаются. MQ надо посадить на свой вариант языка как можно больше людей, чтобы таким образом стимулировать посредников(ДЦ) к покупке продукта. Поэтому полная совместимость им не нужна. Понятно, что затратив большие усилия на адаптацию алгоритмов, трейдеру сложнее будет переходить на альтернативные платформы. Поэтому, имхо, все, что не относится к исполненю торговых команд писать надо на независимых чистых языках. Т.о. можно не связывать себе руки и не тратить время в дальнейшем на переписывание кода. Ведь не секрет, что когда трейдер вырастает, он может уйти к серьезным брокерам, мнгие из которых используют только собственное ПО по соображениям безопасности. Тут библиотеки на независимых языках могут и выручить. Или появится MT 6 (MQ ведь нужны будут новые продажи в будущем), и опять 25 - переписывай все.

Вот-вот. Согласен надо иметь собственную "платформу" для торговли. Я вот ее например и делаю, точнее сделал. Искал соратников одно время но разуверился в том что найти умных и заряженных на успех талантливых программистов, реально. На С++.

[Sergey Kovalyov]

-Alexey-:
Поэтому, имхо, все, что не относится к исполненю торговых команд писать надо на независимых чистых языках.

+1

Хотя, звездастые программисты из джобы с нами не согласятся, конечно. =)

[Renat Fatkhullin]

Наивно.

Это еще допустимо на этапе рассуждений, но до законченной практики практически никогда не доходит.

Я помню себя, когда 13 лет назад написал свой первый независимый терминал FX Charts. Тогда никто и мечтать не мог о наличии платформы с реальным автоматическим исполнением, трейдстейшен и метасток были тогда и потом еще долгое время виртуальными тестерами без реального контроля исполнения.

Сейчас я могу точно утверждать, что МТ5 самая лучшая платформа для написания роботов и программ. Это цельная и чистая система.