Стандартная Библиотека: планируются ли торговые классы и классы торговых стратегий с интерфейсами СБ в МТ5 ?

 

Всех приветствую.

Меня очень порадовало существование Стандартной Библиотеки в МТ4 bulild 600, с одинаковыми интерфейсами для базовых классов. По первой прикидке, все мои классы, написанные для индикаторов МТ5, должны без проблем компилироваться и под МТ4++.

Однако, мои эксперты были разработаны при широком использовании торговых классов и классов торговых стратегий СБ, которых в обновленном МТ4 нет.

Вопрос - это временно ?

Планируется ли написание стандартных торговых классов и классов торговых стратегий, максимально приближенных по интерфейсам к аналогичным классам СБ в МТ5 ?

То есть, вопрос - появятся ли в Стандартной Библиотеке классы:

Торговые:

  • CAccountInfo
  • CSymbolInfo
  • Аналог COrderInfo
  • Аналог CHistoryOrderInfo
  • Аналог CPositionInfo
  • Аналог CDealInfo
  • Аналог CTrade
  • CTerminalInfo

Базовые классыТорговых стратегий:

  • CExpertBase
  • Аналог CExpert
  • CExpertSignal
  • CExpertTrailing
  • CExpertMoney

Понятно, что не все классы будут "чистой калькой" классов МТ5, там, где это, видимо, потребуется - я написал "аналог", но хотелось бы, чтобы их интерфейс был максимально приближенным к классам МТ5.

Надо ли писать все эти классы самому, или в обозримом будущем (скажем, через несколько месяцев) эти классы тоже появятся ?

 

Хм... Обнаружил, что и классы таймсерий СБ4 - заметно отличаются не только по структуре от таймсреий СБ5, но и по интерфейсу, например, есть методы получения одиночных значений, но нет методов получения группы значений.

Отличия во внутренней структуре (в СБ5 в таймсериях есть буффер значений, а в СБ4 - его нет) - не так важны, а вот разница в интерфейсах - серьезно влияет на переносимость кода.

 

Еще новость: В Стандартной Библиотеке отсутствуют не только классы CiTickVolume и CiRealVolume, но и, как ни странно, класс CiSpread !

Пока изучаю фронт работ по переносимости кода. Хотелось бы, чтобы индикаторы и советники, написанные с использованием классов СБ, без изменений компилировались как на МТ4, так и на МТ5.

 
Laryx:

Еще новость: В Стандартной Библиотеке отсутствуют не только классы CiTickVolume и CiRealVolume, но и, как ни странно, класс CiSpread !

Пока изучаю фронт работ по переносимости кода. Хотелось бы, чтобы индикаторы и советники, написанные с использованием классов СБ, без изменений компилировались как на МТ4, так и на МТ5.

Напиши свои классы и не парься в будущем. Ведь неизвестно как поступят MQ по отношению к СБ, может начнут там чего менять.
 
Barbarian:
Напиши свои классы и не парься в будущем. Ведь неизвестно как поступят MQ по отношению к СБ, может начнут там чего менять.


Именно так я и делаю сейчас.

Но все же Стандартная Библиотека - потому и стандартная, что, по крайней мере, ее интерфейсы - остаются максимально стабильными. И, кроме того, будет обидно, если я затрачу довольно много времени на написание своих классов, дублирующих классы СБ от МТ5, а через месяц, в очередном апдейте - все эти классы появятся в СБ от МТ4...

Глядя на классы СБ (по крайней мере, в МТ5) - у меня создается впечатление, что их писали люди, хорошо знакомые с библиотекой MFC от Microsoft, а эта библиотека, несмотря на достаточно значительные изменения во внутренней реализации - была очень стабильна в плане интерфейсов. Хорошо бы, чтобы и СБ от МетаКвотов - тоже была достаточно стабильна в интерфейсах.

 
Laryx:


Именно так я и делаю сейчас.

Но все же Стандартная Библиотека - потому и стандартная, что, по крайней мере, ее интерфейсы - остаются максимально стабильными. И, кроме того, будет обидно, если я затрачу довольно много времени на написание своих классов, дублирующих классы СБ от МТ5, а через месяц, в очередном апдейте - все эти классы появятся в СБ от МТ4...

Глядя на классы СБ (по крайней мере, в МТ5) - у меня создается впечатление, что их писали люди, хорошо знакомые с библиотекой MFC от Microsoft, а эта библиотека, несмотря на достаточно значительные изменения во внутренней реализации - была очень стабильна в плане интерфейсов. Хорошо бы, чтобы и СБ от МетаКвотов - тоже была достаточно стабильна в интерфейсах.

MFC, STL, Boost это библиотеки с мировым именем и писались они не одним программистом, а сообществом. Boost до сих пор дорабатывается сообществом программистов. Я это к тому, что в этих библиотеках реализация может теоретически и измениться, но согласно принятым разработчиками этих библиотек соглашениям, интерфейс библиотек останется неизменным. А в библиотеках MQL5 и MQL4 такого соглашения нет, оно внутри MQ есть скорее всего, но ни кто им не мешает его изменить т.к. публичной оферты этого соглашения нет. Отсюда вывод напрашивается сам собой - либо скопировать стандартную библиотеку себе в отдельное место, либо использовать свою собственную.

Да и вообще, судя по вносимым изменениям в MQL4, говорить о каких либо стандартах смысла нет т.к. этих стандартов для публичной оферты не существует. Утрированно если понимать, то завтра MQ могут спокойно еще чего нить переделать и пользователь вынужден будет в очередной раз либо смириться с данным фактом и использовать дальше их продукт, либо искать альтернативу, благо сейчас с этим проблем особых нет.

 
Barbarian:

А в библиотеках MQL5 и MQL4 такого соглашения нет, оно внутри MQ есть скорее всего, но ни кто им не мешает его изменить т.к. публичной оферты этого соглашения нет. Отсюда вывод напрашивается сам собой - либо скопировать стандартную библиотеку себе в отдельное место, либо использовать свою собственную.

Да, тут я согласен. Но, вроде как MQ все-таки стараются придерживаться принципов стабильности интерфейса. Насколько я понимаю, просто у них была "гонка в хвост и в гриву", и поэтому таймсерии для МТ4 делались наспех, чтобы хоть немного соответствовать МТ5, но в будущем у MQ есть задача унификации. Посему и хотелось бы услышать какую-то информацию от разработчиков.

 
Laryx:

Да, тут я согласен. Но, вроде как MQ все-таки стараются придерживаться принципов стабильности интерфейса. Насколько я понимаю, просто у них была "гонка в хвост и в гриву", и поэтому таймсерии для МТ4 делались наспех, чтобы хоть немного соответствовать МТ5, но в будущем у MQ есть задача унификации. Посему и хотелось бы услышать какую-то информацию от разработчиков.

А откуда такая информация? Пока не опубликуют официально задачу по унификации, опираться как на достоверный факт 100% на этом форуме и даже в сервисдеске не стоит. Могу даже примеры привести:

- Примерно с год назад или чуть больше люди на этом форуме задавали вопрос - будут ли MQ вводить ООП в MQL4. На что получался однозначный ответ - нет. Но по факту, что то произошло в компании и вот ООП введен.

- Когда шло бета-тестирование, я обращался в сервис деск по поводу будут ли вводить множественное наследование в MQL4, на что получил однозначный ответ - нет, однако на форуме кто то из модераторов не так давно давал ответ, что возможно множественное наследование введут.

Таких примеров много, это говорит о том, что нет пока четкого ориентира куда идут MQ. Есть примерное представление чего хотят видеть, но четкого представления конечного продукта похоже нет. Они разработчики им и решать, но факты говорят за то, что если и есть какие то ориентиры, то пользователям это не скажут, что бы в последствии не доставали лишними вопросами и претензиями.

 
Barbarian:

А откуда такая информация? Пока не опубликуют официально задачу по унификации, опираться как на достоверный факт 100% на этом форуме и даже в сервисдеске не стоит.

Дык я вроде ж сказал - "насколько я понял". Это всего лишь предположение. А также вывод из того, что в СБ от МТ5 была весьма стройная иерархия классов. Я вовсе не говорил, что "наверняка".

Могу даже примеры привести:

- Примерно с год назад или чуть больше люди на этом форуме задавали вопрос - будут ли MQ вводить ООП в MQL4. На что получался однозначный ответ - нет. Но по факту, что то произошло в компании и вот ООП введен.

Странно, а я был уверен, что его введут - поскольку все сколь-нибудь серьезные программные структуры без ООП поддерживать очень непросто. Я, правда, думал, что все в конце концов перейдут на МТ5. Но МетаКвоты поступили разумнее. Раз пользователям так дороги локи - то надо чтобы МТ4 вобрал все лучшее от МТ5. Тоже самое - с множественным наследованием.

Но, при этом у меня возникает вопрос - а какая разница тем, кто ООП не использует ? Пусть пишут без ООП, я сам для мелких индикаторов ООП не использую, хотя большой поклонник этой идеологии.

Таких примеров много, это говорит о том, что нет пока четкого ориентира куда идут MQ. Есть примерное представление чего хотят видеть, но четкого представления конечного продукта похоже нет. Они разработчики им и решать, но факты говорят за то, что если и есть какие то ориентиры, то пользователям это не скажут, что бы в последствии не доставали лишними вопросами и претензиями.

Опять же - согласен с замечанием. Тем не менее, планы по структуре и интерфейсам базовых классов в СБ - это явно кратковременные планы. Когда-то они, возможно, изменятся, но, хотелось бы знать, а что сейчас ? Какие планы в отношении ближайшей перспективы ? Будут ли интерфейсы полностью реализованы и унифицированы ? Или так и останутся частичными ?
 

Вы правильные вопросы задаёте! ;)

По озвученным (предположительно, но очень похоже на правду) причинам адекватного ответа от разработчика Вы не получите. А возможных ответов может быть (как минимум) три:

1) Довести до ума (наваянное) по апгрейду языка и оставить "как есть". В этом случае нужно прекратить пудрить мозги народу о возможности использовать в MQL4 СБ, так как она для MQL4 в состоянии "тут играем, а тут не играем".

2) Двигаться дальше по пути "приведения к похожести" MQL4 и MQL5. И в этом случае СБ для MQL4 всё равно будет "седлом для коровы".

3) Самый простой, но самый тяжёлый: есть современный язык (MQL5) - уберите совокупную позицию и дайте возможность работы в тестере с кастомной историей - И ВСЕМ БУДЕТ СЧАСТЬЕ!!!

Как Вы думаете будут развиваться события??? Через 1 год? Через 2 года? Через 5 лет??? :)))

 

Ну, вариант 1 мне не очень нравится - придется писать все классы СБ, которые я использую весьма и весьма широко. Но, с другой стороны, если никаких разработок не предусмотрено - то все в порядке, труд даром не пропадает.

Насчет варианта 3 - полностью поддерживаю требование о кастомной истории в отладчике и тестере - очень нужная фича. Насчет же "уберите совокупную позицию" - совершенно не согласен, что это "самый простой вариант". Для подобного шага во-первых, следует менять серверную часть ПО. Во-вторых, это на мой взгляд, совершенно неверный шаг потому, что реально на бирже существует ОДНА позиция, а все эти игры с приказами и локами - это лишь видимость. Ну и в-третьих, линия Эквити одной ТС совершенно одна и та же хоть с локированием, хоть без локирования. Локи - же только вводят в заблуждение. Пока мне еще никто не показал ТС, которая бы с локами работала бы, а без локов - нет (ну или наоборот).

Вариант 2 - опять же не согласен. Почему "седло для коровы" ? СБ - замечательная штука, позволяет абстраггировать ТС от платформы. Заменяя классы СБ - вы сможете один и тот же код сотни советников легко перекомпилировать хоть для МТ4, хоть для МТ5 и даже для, скажем, WLD.


Спрашиваю же я в основном для того, чтобы не делать дурную работу - сейчас я напишу отсутствующие классы, а через неделю выйдет апдейт, в котором эти классы будут входить в СБ - и зачем тогда мне терять время ?