А почему бы не поместить входные параметры в структуру?

Новый комментарий
 

Я про подход "советник в классе". Есть проблема передачи входных параметров в советник, класс которого находится в отдельном .mqh файле. Я использую два способа

  1. Входные параметры копируются в поля класса советника одной или несколькими функциями инициализации. Самый универсальный подход, но в случае большого количества переменных самый трудоемкий.
  2. Класс определяется после входных переменных, т.о. они видны из советника. Недостаток - меньше гибкости в случае использования множества экземпляров класса. Плюс - минимум писанины.

input double LotSize = 0.1;
// другие input переменные...

#include <MyLib\MyClassEA.mqh>
CMyClassEA MyEA;

А что, если сделать расширение языка MQL и помещать входные переменные в структуру? Все равно с С++ и С он не совместим по причине имитации указателей. Так почему бы не пойти дальше?

struct InputVars
{
    input double Lot   = 0.1;
    input int    Magik = 100;
} ivars;

Тогда можно было бы переменную ivars передавать в класс алгоритма, копировать и т.д.

Воспринимайте идею на уровне мозгового штурма ))

 

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

Вот если бы было что-то подобное в MQL, чтобы не листать огромный список параметров. Само предложение, как это оформить, интересное. Только синтаксис напрашивается несколько другой:

input struct VolumeParams                              // Здесь название вкладки
{
    // Содержимое вкладки
    double Lot1 = 0.01;
    double Lot2 = 0.02;
    double LotRatio = 1.5;
};
 
Ihor Herasko:

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

Вот если бы было что-то подобное в MQL, чтобы не листать огромный список параметров. Само предложение, как это оформить, интересное. Только синтаксис напрашивается несколько другой:


верно, так короче ) а с dll не пройдет в Маркет, увы.

и использование диалогового окна не даст оптимизировать параметры в тестере

 

тогда уж лучше так:

struct VolumeParams                              
{
    double lot;         //название параметра
    double LotRatio;    //название параметра
    int tp;             //название параметра
    int sl;             //название параметра
    int orders;         //название параметра
};
VolumeParams ParamBuf[5];

input ParamBuf[0];         // Здесь название вкладки
input ParamBuf[1];         // Здесь название вкладки
input ParamBuf[2];         // Здесь название вкладки
input ParamBuf[3];         // Здесь название вкладки
input ParamBuf[4];         // Здесь название вкладки
 

Имхо, отличная идея, соответствует концепции ООП. Пока вижу 2 варианта:

1) в стиле FrameInputs

parameters

[out]  Строковый массив с описанием имен и значений параметров

parameters_count

[out]  Количество элементов в массиве parameters[].

2) в стиле MqlParams.

 

Я всегда использую первый подход.

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

 
Alexey Volchanskiy:

Я про подход "советник в классе". Есть проблема передачи входных параметров в советник, класс которого находится в отдельном .mqh файле.

Не прочувствовал проблемы. Шаблон в конструкторе класса прописать и все.

 
fxsaber:

Не прочувствовал проблемы. Шаблон в конструкторе класса прописать и все.


ну, вы с клиентами не общались)

...вот заказчик хочет 10 входов, и у каждого шага свои тп/сл/лот/тралл/сигнал на вход

и чтобы это всё оптимизировалось в тестере)

 
Taras Slobodyanik:

ну, вы с клиентами не общались)

...вот заказчик хочет 10 входов, и у каждого шага свои тп/сл/лот/тралл/сигнал на вход

и чтобы это всё оптимизировалось в тестере)

Так а как это соотносится с темой ветки?

 
fxsaber:

Так а как это соотносится с темой ветки?


Само обсуждение, действительно, немного отклонилось от названия ветки. Сейчас больше обсуждается вторая часть поста ТС:

Alexey Volchanskiy

А что, если сделать расширение языка MQL и помещать входные переменные в структуру? Все равно с С++ и С он не совместим по причине имитации указателей. Так почему бы не пойти дальше?

Тогда можно было бы переменную ivars передавать в класс алгоритма, копировать и т.д.

 
fxsaber:

Так а как это соотносится с темой ветки?


Так и относится, для написания всей этой кучи параметров, достаточно будет определить структуру и вынести ее во входные параметры.

1234567
Новый комментарий