Будет ли востребовано ООП в MQL5? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Хорошо хоть освоение MQL4 не пройдет даром. Если пользовался только обыкновенными индикаторами - переделать,как я понял,будет не очень сложно.
А так думаю,среднестатистическому полупрофессиональному программеру - ООП в MQL5 не понадобится.
А вообще при первом приближении - если скорость заметно прирастет во всём - хорошо,а так из плюсов пока не особо просматриваю,чтобы такие,что решают большие проблемы. Повторюсь - я не профессионал.
Хотя может теперь энтузиасты будут моделировать на MQL5 зарождение жизни из первичного бульона ? ;)
P/S Забыл. Функции обработки событий. Гуд.
... библиотека возвращает интерфейс (класс с виртуальными функциями). В случае с "несогласованным" со мной использованием возвращает интерфейс заглушку (с не очень явными косяками в расчётах).
а без мата можно? здесь же иногда женщины на форум заходят.
Будет польза в защите - EX5 библиотека возвращает интерфейс (класс с виртуальными функциями). В случае с "несогласованным" со мной использованием возвращает интерфейс заглушку (с не очень явными косяками в расчётах).
если будет того стоить - взломают, тут интерфейс с чистенькими гуманоидами не поможет :)
поэтому, защита только как и везде - отсутствие физического доступа к коду, плюс необходимая для конкретной ТС задержка с обозрением сделок (эквити инвестору можно давать реал тайм).
ну а ООП в советниках штука весьма ценная, начиная от событий, возможности грамотной поддержки и доработки, и т.п. Конечно, не понятно чем C# не подошёл, ведь отсутствие MQL5 framework с чёткими namespace декларациями, а также нестандартность+неспелость языка потребует бОльших чем было бы изначально целесообразно усилий от всех :(
У них уже в основе не ООП (хотя абсолютное ООП практически не удобно). Нужно было изначально создавать абстрактные классы и доходить с помощью наследование и полиморфизма до реальных объектов. Например, базовый абстрактный класс для пользовательских индикаторов с абстрактыми методами и свойствами. Короче строить иерархическое дерево классов: свое дерево и для графических объектов, для работы со счетом, для графиков и доступа к тайм-сериям и т.д. А на предопределенные процедуры и функции оставить только элементарную рутину требующую быстродействия. Тогда можно было бы расширять возможности платформы с любого уровня абстракции, что значительно сократило бы код, улучшило читаемость и простоту его понимания другими программерами. А в МТ5 уже реализованы довольно сложные вещи на уровне процедур (фактически вся готовая к использованию платформа) и я не увидел возможности доступа по указателям хотя бы к дескрипторам создаваемых внутренних структур, что весьма ограничит возможности (судя по хелпу). Да и вообще необходимость ООП под вопросом, при такой реализации можно было ограничится структурами и динамическим размещением. ООП должно быть поддержено снизу разветвленной иерархией классов. имха
Да. Вот и я о том же. Так, как сделано, ИМХО, вряд ли будет сильно полезным. Для чего и сабж. Но, все-таки, может, др. мнения есть?
Whistles'n'Bells, однозначно. Впрочем, если будет хоть какая-нибудь поддержка внешних объектов, то сие есть гут.
Без именованных пространств (namespaces) нормальную поддержку обеспечить будет не совсем реально.
Без именованных пространств (namespaces) нормальную поддержку обеспечить будет не совсем реально.
Можно и без этого новейшего выпендрёжа от мелкософта. Однако совсем без мелкомягких изгалений вроде ' библиотек интерфейсов ' не обойтись, по крайней мере, пока речь идёт о винде. Вообще очень жаль, что разработчики МТ, видимо, поклялись мелкомягким в несокрушимой верности до гроба, и на всё остальное вовсе не обращают внимания. Уже нутром чую, что заставить даже полностью безгрешный МТ5 работать под линуксом через вайн это будет тот ещё геморрой, мама не горюй.