Вопросы по индикаторам в МТ5 - страница 4

Проблема в том, что невозможно было нормально тестировать индикаторы, у которых объекты строились от данных с другого таймфрейма.

А на текущем таймфрейме никаких проблем. Но, по слухам, в МТ5 c различными таймфреймами будет нормально. Поэтому не вижу проблем у индикаторов с объектами.

Это все на примере тестирования ZUP, а в нем объектов было очень много. Объекты "с другого таймфрейма" не желали в тестере нормально работать, а с текущего работают не жалуются.

Вопрос.

Создаем класс для графического объекта. Потом на основе этого класса создаем несколько объектов.

При этом отводится в памяти под каждый объект место.

Так вот вопрос. В каждом экземпляре объекта данного класса будут храниться коды методов объекта?

Или эти коды будут храниться в единственном экземпляре где-то? По сути методы в каждом экземпляре класса одинаковые, а вот данные разные.

Как это решено в МQL5 ?

Хорошо бы увидеть блок схему расположения в памяти данных и методов объектов для лучшего понимания.

Если коды методов копируются в каждый экземпляр объекта, то становится понятно, почему работа с объектами будет требовать больших ресурсов (по крайней мере, потребуется много памяти).

------------

Для управления графическими объектами могут потребоваться очень сложные методы. Большой объем кода.

Евгений, смотрели ли вы раздел "Справочник MQL5" — "Основы языка" — "Объектно-ориентированное программирование"?

Для каждого класса создается таблица вызовов функций-методов.

Я сейчас повторяю теорию. По книге Лафоре. С ООП знакомился впервые где-то лет 15 назад. Автора книги уже и не помню. Применял (ю) ООП немного для программирования с помощью WSH (в урезанном виде) для автоматизации некоторых расчетов.

Решил сначала освежить основы.

Раздел из Справочника пока не смотрел....

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

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

Рухнула последняя надежда... (((

Зациклившись на графических функциях как-то упустил из виду коммент.

Ну ладноть, обьекты низзя, так хоть просто текстом тоже можно инфу полезную вывести.

Да вот оказалось индейское жилище...

*

Одно пока греет душу, при добавлении в каждый советник не сильно усложнит и не распухнет код.

Не беспокойтесь, рисовать сложные объекты можно будет. Но не из индикаторов :)

Скорее всего разрешим множество экспертов на одном графике.

ок!

:)

А сложные объекты на основе данных, полученных от индикаторов?

Есть, допустим, RSI. К кривой этого индикатора по касательной строится трендовая или что-то более сложное.

Как в этом случае быть?

Чтобы такую конструкцию построить также необходимо будет создавать эксперт?

А просто чистая RSI уже в виде индикатора?

Путаница получается.

............

Может тогда лучше все индикаторы создавать как эксперты? А про OnCalculate забыть, как про страшный сон...?

...........

Это самые простые случае, лежащие просто на поверхности.

...........

Может быть, не стоит торопиться с выводом MT5 и MQL5 на рынок? А лучше более тщательно продумать архитектуру.

Несколько лет назад многие трейдеры искали различные экзотических способы создания сложных графических построений.

По их мнению, метатрейдер не позволял это делать. И сейчас есть те, кто так считает.

В последнее время появилось большое количество разработок, устраняющие эти пробелы в метатрейдере.

Это в том числе явилось катализатором более массового использования метатрейдера.

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

Поддерживаю.

На мой взгляд, основной упор должен быть сделан на потребительские свойства платформы.

В качестве аналога можно привести автомобиль. Удобные и понятные средства управления позволяют управлять автомобилем любой блондинке. При этом от неё не требуется знать особенности отношений между АКП и двигателем.

Но одновременно с этим (несмотря на обширный опыт и множество аналогов) неудачные техн. решения всё же воплощаются в жизнь. Например, существуют такие экземпляры автомобилей, у которых ручка перекл. передач находится аккурат за спиной водителя, в районе правой ягодицы. Это очень неудобно, хотя и работоспособно. Если бы конструктора спросить, то он аргументировал бы своё решение как правильное и оправданное.

На руле моего авто есть две небольшие кнопки по бокам для подачи звукового сигнала "пи-пип". Это тоже неудобно. При повороте руля хрен ты попадёшь в эти маленькие кнопки, чтоб просигналить пешеходу. Спрашиваю у менеджера "почему не вся поверхность внутренней части руля?" Он смотрит на меня, как на умалишённого, и отвечает: "Дык, там же подушка безопасности!" Ё-маё.. Так и хотелось трахнуть его по башке! Я ограничился риторическим вопросом: "А в моделях других производителей что.. подушки в руле нет?" Он молчит и лупает глазами. Но он - менеджер по продажам, что с него взять. А конструктор..?

Чем отличается хорошее изделие от так-себе? Потребительскими свойствами с точки зрения пользователя, которые могут быть обеспечены в результате правильной постановкой задачи с т.з. конструктора. Техн. решения должны быть подчинены приоритетной задаче - потребительским свойствам конечного продукта.

--

(на мой взгляд) От МТ ожидается:

- упорядочивание свойств прикладных программ (пп) (эксперты и скрипты должны торговать, индикаторы - рисовать) + обмен данными; в том числе, возможность получать список пп, исполняемых в окне, и их параметрах;

- возможность программного вызова пп в соответствии с иерархией подчинения (эксперт-скрипт-индикатор);

- возможность создания полноценных пп без использования DLL (необходимость использования программистами DLL следует расценивать как недостаток платформы);

- возможность создания в МЕ полноценного интерфейса (создание меню, кнопок, окон, закладок на панели настроек пп, выпадающих списков, встроенного хелпа к input-параметрам и т.д.);

- возможность обмена данными (как сообщениями, так и управляющими сигналами) между клиентскими терминалами; ПАММ - это хорошо, но многие управляющие захотят иметь и такую возможность, к тому же, на инвесторском терминале можно было бы как принимать, так и отклонять упр. сигналы; реализация такой возможности приведёт к образованию множества "групп по интересам", причём все они будут привязаны к МТ;

- возможность получать данные со сторонних серверов (получить файл данных, положить его в нужное место, прочитать его, программно обрабатывать его данные; выводить картинки в отдельное окно или в указанное окно, подокно);

- мультивалютный тестер (принципиальных ограничений по обработке тех или иных данных, на мой взгляд, не существует, возможны только неудачные техн. решения, противоречащие идее обеспечения нужных потреб. свойств);

- возможность моделирования при тестировании на основе настраиваемых пользовательских значений (а не диктуемых сервером), и в автономном режиме (без подкл. к Интернет);

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

.

Конечно, это не весь список.. Наверное, в своё время, наряду с Пожеланиями к MQL 5, нужно было создать ветку Пожелания к МТ5.