Обсуждение статьи "Библиотека для простого и быстрого создания программ для MetaTrader (Часть I). Концепция, организация данных, первые результаты" - страница 3

 
Stanislav Korotky:

Если оставить "пока так", потом кучу кода придется менять, если переделывать локализацию. В чем сложность сразу подключать строки из "ресурсных" библиотек или заголовков?

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

 
Stanislav Korotky:

Если оставить "пока так", потом кучу кода придется менять, если переделывать локализацию. В чем сложность сразу подключать строки из "ресурсных" библиотек или заголовков?

Всё имеет свой черёд. На данном этапе создания библиотеки у неё нет ещё класса сообщений. При его создании всё будет. Я не стараюсь бежать впереди паровоза и придерживаюсь принципа "от простого к сложному", тем более, я уже писал:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Обсуждение статьи "Библиотека для простого и быстрого создания программ для MetaTrader (Часть I). Концепция, организация данных, первые результаты"

Artyom Trishkin, 2019.02.27 19:25

Ну возврат структур планируется как дополнительная возможность по запросу пользователя - сугубо для удобства. Там далее видно будет. В любом случае - библиотека создаётся "на лету" с описанием шагов её создания, с внесением изменений. Так что далее будет видно как сделать "не дорого".

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

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


 
Artyom Trishkin:

Всё имеет свой черёд. На данном этапе создания библиотеки у неё нет ещё класса сообщений. При его создании всё будет. Я не стараюсь бежать впереди паровоза и придерживаюсь принципа "от простого к сложному", тем более, я уже писал:

Это я читал. Просто, если до локализации план работ еще не дошел, то зачем надо было вообще её вставлять в том виде, как сейчас? В общем, хозяин - барин, вопрос риторический.

 
Stanislav Korotky:

Это я читал. Просто, если до локализации план работ еще не дошел, то зачем надо было вообще её вставлять в том виде, как сейчас? В общем, хозяин - барин, вопрос риторический.

План давно расписан. И менять его не буду. Это лишь первая часть - самое начало, рассказ об общей концепции, без деталей. И если вы внимательны, то ваш вопрос весьма странен. 
Странно предъявлять претензии к раме автомобиля, что в ней не предусмотрен люк в крыше кузова, который ещё вами не увиден.
 
Artyom Trishkin:
План давно расписан. И менять его не буду. Это лишь первая часть - самое начало, рассказ об общей концепции, без деталей. И если вы внимательны, то ваш вопрос весьма странен. 
Странно предъявлять претензии к раме автомобиля, что в ней не предусмотрен люк в крыше кузова, который ещё вами не увиден.

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

 
Stanislav Korotky:

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

Вы при отладке, если вам нужно что-либо вывести в журнал, обязательно пишете целый класс, чтобы он вам выводил на языке племени томбо записи в журнал? Особенно, если требуется показать в статье этот вывод? Отладчик в статье не покажешь. В общем - не побегу впереди паровоза. Тем более, что класс запланирован, и будет показан именно в той статье, где это к месту и контексту. 
 
fxsaber:

Возвращать структуру - дорого. По этой же причине CopyRates в несколько раз дороже CopyClose.

Серьёзно? Я просто полагал что встроенная структура должна работать эффективно. т.е. если мне нужно скопировать все поля MqlRates, то использовать CopyRates должно быть эффективнее, чем использовать  CopyTime, CopyOpen, CopyHigh ... все восемь функций последовательно.
 
alex_all:
Серьёзно? Я просто полагал что встроенная структура должна работать эффективно. т.е. если мне нужно скопировать все поля MqlRates, то использовать CopyRates должно быть эффективнее, чем использовать  CopyTime, CopyOpen, CopyHigh ... все восемь функций последовательно.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Новая версия платформы MetaTrader 5 build 1930: Плавающие окна графиков и .Net библиотеки в MQL5

Renat Fatkhullin, 2018.12.10 19:31

Я забыл сразу объяснить важную особенность хранения данных баров в МТ5. В МТ5 бары хранятся в виде отдельных массивов Open, High, Low, Close, Volume. Это означает, что для создания MqlRates бара в функции CopyRates нам нужно собирать структуру ценового бара из множества массивов.

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


Почему у нас разделены массивы данных в МТ5? Потому что так эффективнее работать и особенно для отдельных функций CopyClose, CopyHigh, High[], Low[] и тд. Очень много мест, где используются конкретные показатели без необходимости обращений ко всему бару.

 
alex_all:
Серьёзно? Я просто полагал что встроенная структура должна работать эффективно. т.е. если мне нужно скопировать все поля MqlRates, то использовать CopyRates должно быть эффективнее, чем использовать  CopyTime, CopyOpen, CopyHigh ... все восемь функций последовательно.

Всё же, дать наружу указатель на объект, с которого можно получить далее все его свойства в программе, будет-таки быстрее, нежели копировать все свойства объекта в структуру, переданную в класс по ссылке.

 
Artyom Trishkin:

Всё же, дать наружу указатель на объект, с которого можно получить далее все его свойства в программе, будет-таки быстрее, нежели копировать все свойства объекта в структуру, переданную в класс по ссылке.

Правильно понимаю, что вы хотите сказать - CopyRates  выполняет копирование данных реальное в структуру, а семейство CopyOpen... - виртуальное (т.е. перезапись ссылки на имеющийся массив)?

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

Причина обращения: