iCustom() в MQL5: нужна ли унификация функции?
Давненько думал (без последствий) о том, что стоило бы во все свои индикаторы передавать единственный строковой параметр (CSV), а в стартовом коде парсить эту строчку.
Для этого требуется WinAPI, не так ли?
Я создал эту тему не с целью решения тех проблем, а для того, чтобы все вместе поискали аргументы, убеждающие разработчиков терминала унифицировать ее (естественно, в пределах языка). Или понять, что эта тема не актуальна.
Для этого требуется WinAPI, не так ли?
Я создал эту тему не с целью решения тех проблем, а для того, чтобы все вместе поискали аргументы, убеждающие разработчиков терминала унифицировать ее (естественно, в пределах языка). Или понять, что эта тема не актуальна.
WinAPI не при чем. В C и C++ есть понятие указателя на функцию. Надеюсь, в MQL5 тоже будет.
Кстати, есть еще одно предложение: запихнуть имя индикатора в соответствующий строковый массив (строковый список). Это же фактически внешний параметр индикатора.
MQL5 и С++ - довольно похожие, но все равно очень разные языки для разных применений. Наивно ожидать, что в MQL5 будут все примочки С++.
2 lea: я это даже реализовывал, но только для подмножества внешних параметров. Это был список разных пропорций Фибоначчи (размер списка был переменным). Парсинг был несложным, но чувствовалось, что это как-то не по-человечески.
Указатели на переменные и на функции присутствуют даже в классическом Си. Неужели MQL5 примитивнее?!
getch, Ваш подход не конструктивен. Задача совсем не в том, чтобы сделать MQL5 не менее мощным,чем С или С++, а в том, чтобы он сооветствовал области своего применения и был удобным для его пользователей.
P.S. Еще одно дополнение: унифицированный вариант вызова функции не обязан быть единственно возможным. Это может быть просто второй вариант вызова. Именно так и была недавно модифицирована функция GlobalVariableGet().
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Добрый день, коллеги.
Из Хелпа к MQL5 можно видеть, что внешний вид вызова этой функции слегка изменился (последние параметры - номер буфера и сдвиг, - исчезли, и теперь после входных параметров ничего нет). Я считаю, что такого изменения функции не достаточно.
Выкладываю переписку с Техподдержкой касательно этой функции.
Sceptic Philozoff 2009.08.23 01:34
Входными параметрами (input) пользовательского индикатора могут быть фактически только числа (целые, вещественные, енумераторы) и строки. Почему бы не организовать их все в единую структуру? При этом вызов iCustom() получается таким:
iCustom( symbol, tf, name, inputStruct )
Во всяком случае хотя бы количество параметров функции iCustom() для кодера становится постоянным.
Далее, саму структуру можно дополнительно организовать для ее же собственной унификации (опять же для кодеров). Хотя это и не принято и считается дурным тоном, но в данном случае можно сделать исключение: членами структуры являются массивы (соответственно long, double и string). Естественно, их размеры для данного индикатора постоянны. При этом структура будет иметь только три члена (три массива) навсегда заданных типов (аналогично вызову функции обработки события чарта, имеющего максимум по одному параметру заданных типов).
Вместо массивов-членов структуры inputStruct можно сделать списки.
Это предложение - именно для программистов, кодирующих на MQL5, а не для пользователей МТ5. Для пользователей все остается так же, как было, т.е. обычный список параметров в окне изменения свойств индикатора. При этом возникают проблемы для кодера (в окне свойств индикатора отображается совсем не то, что он будет кодить), но пусть это будут только проблемы кодера. Он с ними точно справится.
Если вы спросите меня, зачем эта унификация, пока я смогу ответить лишь "А шоб було...". Но постараюсь найти достойные аргументы.
Stanislav Starikov 2009.08.23 09:31
Подумаем.
А Вы пока найдите достойные аргументы
Sceptic Philozoff 2009.08.23 22:12
Первое - удобство для кодера и концептуальное единство. Вместо пестрой последовательности внешних параметров, перечисляемых в функции iCustom() (и в которой легко запутаться, если параметров порядка десяти или больше), удобнее иметь нечто единое и концептуально простое. Отдельно - целые параметры, отдельно - вещественные, отдельно - строчные. А все вместе - структура.
Дополнительные примеры такой унификации в языке легко найти.
Вы сами разделили свойства индикаторов на целые, вещественные и строчные и сделали соответствующие единые, унифицированные функции (примеры - IndicatorSetString(), PlotIndexSetInteger() и прочее), т.е. вместо зоопарка разнородных функций конструируете всего несколько делающих то же самое, а всю "смысловую" нагрузку функций переносите на параметры енумераторных типов.
Та же унификация получилась с графическими объектами. Правда, мне показалось, не совсем последовательно: ObjectName(), вероятно, можно было бы реализовать и через ObjectGetString() - но, возможно, это не так просто.
Это пока только концептуальный аргумент.
Второй будет чуть попозже, надо кое-что найти.
Sceptic Philozoff 2009.08.24 00:42
Второй аргумент - тема https://forum.mql4.com/ru/6955. Я не знаю, для чего автор задавался таким вопросом. Но это логичный вопрос (у меня он тоже возник, и только потом я эту тему увидел).
К параметрам индикатора должен быть программный доступ - ну, скажем, если inputStruct сделать параметром типа [in/out] (с передачей по ссылке). С существующей структурой параметров iCustom(), если, скажем, ко мне попал уже скомпилированный индикатор, параметры можно вытащить только через диалог параметров, т.е. вручную.
Гипотетическая ситуация может быть такой. Допустим, я поставил задачу исследования эффективности разных индикаторов на истории. Их у меня пара сотен. Я пишу программный код, который последовательно перебирает все эти индикаторы и на их основе открывает/закрывает ордеры. Вручную открывать диалог свойств для каждого индикатора, чтобы запомнить конкретный вызов iCustom() именно для него, слишком утомительно. А тут - полная автоматизация.
Кстати, я не настаиваю именно на структуре inputStruct. Параметры можно описать и просто тремя массивами (списками) типов long, double, string. Самое главное тут - унификация вызова iCustom().
Думаю над очередными аргументами. Может быть, есть смысл создать тему на форуме, чтобы подключился народ? Функция слишком важная, чтобы принимать поспешные решения о ее архитектуре.
-------------------------------------------------------------------------------
Это пока все аргументы, которые я смог найти. Приглашаю всех (абсолютно всех, не только бета-тестеров!) высказываться по теме. Абсолютно уверен, что способность многих найти достойные аргументы - в случае, если этот шаг обоснован и логичен, - гораздо выше способности одного человека.
chv, Вам особое приглашение: Вы до этого были чуть ли не единственным, кто эту тему поднимал. Очень интересны Ваши аргументы.