Мысля по развитию языка mql4

Новый комментарий
 
Пишу сейчас библиотеку для подключения к матлабу(впрочем не только к нему одному). И понадобилась система глобального оповещения и передачи данных в терминале. В этой связи очень сильно пожалел, что глобальные переменные могут быть только типа double. Как было бы здорово и удобно, если бы в глобальных переменных можно было передавать double[] и string ! Господа разработчики, может замутите эту фичу ? Наверняка ведь сделать нетрудно ! Я конечно сейчас включу мозги и выкручусь, но на будущее хотелось бы это иметь.
 
Кстати.. а мне не хватает ООП. Но он только в MQL5 наверное будет. %)
 
Люди, а сколько максимально памяти можно выделить под массив, есть ли ограничения?
 
njel писал (а):
Кстати.. а мне не хватает ООП. Но он только в MQL5 наверное будет. %)

Смотря в каком виде? Если по полной программе C++, то это полиморфизм, виртуальные перекрываемые методы, перегрузка методов и операторов, спецификаторы доступа (public, protected, private, в C# ещё internal внутри сборок), множественное наследование, в C# заменённое на реализацию интейфейсов, и т.д.

Вряд ли это всё нужно в MQL4, и мы это увидим в нём.
 
Вот перечислений (enum) реально не хватает, с возможностью их перебора оптимизатором.
 
МТ - это система реального времени ..
И в нем явно не хватает обработки событий (фактически есть одно - приход тика).
Отсюда много всяких извращений в написании кода ...
 
Народ, давайте будем реалистами, а то вы мне напоминаете меня самого весной, когда я только-только тут появился и требовал чтобы кровь из носу эксперты работали в версии для КПК :)))))))))))) Что такое ООП, за 20 лет опыта программирования я так и не врубился. Наверно тупой. Пока мне кажется что это что-то типа самых крутых в мире женских прокладок олвейс. Объектно-ориентированно значит круто. Тупой рекламной шумихи вокруг этого гораздо больше чем реальной пользы. Сам я могу перечислить по пальцам двух рук случаи, когда пользовался методами ООП по собственной инициативе. Не когда надо было окошки на MFC рисовать и создавать для этого классы, а когда оно реально облегчало мне решение задачи. И все без исключения такие случаи были из области имитационного моделирования и распространения сигналов в графах. Кстати что характерно, если мы вспомним историю, то впервые ООП появилось как раз в языке имитационного моделирования Simula68. А в изящный и продуманный язык С, эта напасть проникла именно в связи с задачей моделирования крупной телефонной станции... В приложении к торговле на форексе, у меня что-то слабо получается представить себе подобные ситуации. .. Вот структуры нужны реально, тут я обеими руками и всеми шестью ногами за... :) И надеюсь в mql5 мы их всё-таки увидим. Что же касается первоначального моего предложения, похоже в билде 199 нас ожидает сюрприз. Конечно не то, чего я хотел, но всё-таки существенное улучшение поддержки глобальных переменных. Вот жду не дождусь официального релиза...

Mak, обработку событий одобрямссс !!! Тем более сделать это по-моему тоже достаточно легко.
 
И все без исключения такие случаи были из области имитационного моделирования ..

А эксперты, как системы реального времени, в общем из этой области .. :))
Для меня эксперт - это машина состоящая из взаимодействующих блоков, работающая в реальном времени, получающая на входе котировки и состояние счета и позиций, и выдающая на выходе управляющие воздействия - открытия/модификации ордеров ...

Т.е. для меня эксперт - это АСУ ТП :)
(Автоматизированная система управления технологическим процессом)
Для такой системы естественным будет и обработка событий,
и объектная ориентация (деление системы на замкнутые функциональные блоки),
и взаимодействие блоков через поток сообщений или событий . . .

Это было бы круто ..
Но ИМХО, в рамках МТ вряд ли будет сделано.
 
Mak, я согласен. Любую (наверно всё-таки в разумных пределах) задачу, можно представить как задачу имитационного моделирования. Например задачу движения Земли по орбите вокруг Солнца. Очень просто. Солнце задает гравитационное поле. Земля в окрестности своего текущего положения делает маленькие пробные шажки в случайных направлениях. Господь Бог взирает на этот небесный цирк с облака и скурупулезно суммирует лагранжиан по всей ранее пройденной орбите плюс в текущем пробном шажке. Те шажки Земли, которые наименее увеличивают полученную сумму, Господом Богом принимаются и становятся в модели реальными. Вот тебе система из трех взаимодействующих объектов. Земли, Солнца и Господа Бога. Для каждого из них можно ввести состояние, описываемое приватными членами. Каждому из них можно сконструировать public интерфейсы. От каждого можно вывести производные классы, хоть с единичным, хоть с множественным наследованием... Только проще было бы воспользоваться законами Кеплера. И вообще мне кажется, увлечение ООП сильно испортило программистов. Они перестали видеть простые и лаконичные решения. В свое время меня совершенно убил наповал пример Андрея Черезова (отличный мужик, энтузиаст языка Forth), который сравнивал Forth с Java. На Java программа "Hello, world !" пишется так:

class HelloWorld
{
public static void main(String args[])
{
System.out.println("Hello, world !");
}
}

А вот точно та же программа на Forth:

: HelloWorld ." Hello, world !" ;

Разница как мы видим заметная. Вот в этой разнице зачастую "вся мощь ООП" и заключена.

Кстати, сообщения и события это совсем не обязательно прерогатива ООП. Я глянул твой профайл, мы с тобой коллеги. Оба любители матлаба. Там есть такая штука как callback. Если программировал в матлабе приложения с GUI, знаешь, что это такое. Ну и где же в этом объекты ??? Еще пример. Функция qsort из стандартной сишной библиотеки. Она пользуется передаваемой функцией сравнения. Вот тебе и полиморфизм. В рамках чистейшего, классического С. Опять таки, где здесь объекты ? :)
 
Вот чего действительно не хватает в MQL4, так это отладчика!
 
stator, да я уже привонялся к этому как-то... В наиболее тяжелых случаях отлаживаюсь через dll в Visual Studio. Хотя конечно оно было бы неплохо. ..
12
Новый комментарий