Ошибки, баги, вопросы - страница 1667

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

Удалось составить проверочный скрипт близкий к исходной программе с ошибкой при выполнении

Результат: invalid function pointer call in 'Script2.mq5'

build 1405. Сама по себе эта ошибка осталась - переместившись в другую часть программы - разберусь позже

Но появились новые, которых раньше не было

typedef int (*fn)();
class A {
public:
        A() { a = &this; ::ArrayResize( f, 1 ); f[ 0 ] = f0; }
        virtual int g0() { return 0; }
        static  int f0() { return a.g0(); }
        static A* a;
        fn f[];
};
A* A::a;
void OnStart() { A b; }
Результат: invalid EX5 file (8)
Как сделать, чтобы в отладке по Shift+F9 были видны элементы массива?
fxsaber:
Как сделать, чтобы в отладке по Shift+F9 были видны элементы массива?
Показ элементов массивов пока не поддерживается
Renat Fatkhullin:

Фактически в 99% случаев вызов IndicatorRelease является логической ошибкой программиста.

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

Это же очень просто понять.

Правильно ли я понимаю, что при использовании iCustom вместо IndicatorCreate пользователь перекладывает ответственность за IndicatorRelease на универсальное (поэтому не оптимальное) решение разработчиков?

В котором созданные индикаторы хранятся некоторые время, пока к ним с определенной частотой идет обращение. Если обращения какое-то время нет, то идет принудительное IndicatorRelease. Верно?

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

Правильно ли я понял? 

fxsaber:

Правильно ли я понимаю, что при использовании iCustom вместо IndicatorCreate пользователь перекладывает ответственность за IndicatorRelease на универсальное (поэтому не оптимальное) решение разработчиков?

В котором созданные индикаторы хранятся некоторые время, пока к ним с определенной частотой идет обращение. Если обращения какое-то время нет, то идет принудительное IndicatorRelease. Верно?

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

Правильно ли я понял? 

Нет, неправильно.

Обе функции совершенно равнозначны. И та, и другая функция возвращает хэндл индикатора

Slawa:

Нет, неправильно.

Обе функции совершенно равнозначны. И та, и другая функция возвращает хэндл индикатора

IndicatorRelease после iCustom делать надо?

В принципе получается, что вполне возможно MT4-советники запускать в MT5. Для тех, кто не использует внутри другие индикаторы - совсем просто. Использует - повозиться с созданием аналога хранилища MT4-iCustom. Вопросы неподготовки данных тоже решить вполне возможно.

Написать такой переходник и любой MT4-индикатор будет благополучно запускаться в MT5. Но тогда лишится работы Николай Косицын... не, лучше не буду.

fxsaber:

IndicatorRelease после iCustom делать надо?

В принципе получается, что вполне возможно MT4-советники запускать в MT5. Для тех, кто не использует внутри другие индикаторы - совсем просто. Использует - повозиться с созданием аналога хранилища MT4-iCustom. Вопросы неподготовки данных тоже решить вполне возможно.

Написать такой переходник и любой MT4-индикатор будет благополучно запускаться в MT5. Но тогда лишится работы Николай Косицын... не, лучше не буду.

ЕМНИП, в Документации написано, что правильнее всего инициализировать (создавать) хэндлы индикаторов в функции OnInit, а выполнять IndicatorRelease в функции OnDeinit. Т.е. всё время, пока советник работает, хэндлы индикаторов остаются актуальными.
BlackTomcat:
ЕМНИП, в Документации написано, что правильнее всего инициализировать (создавать) хэндлы индикаторов в функции OnInit, а выполнять IndicatorRelease в функции OnDeinit. Т.е. всё время, пока советник работает, хэндлы индикаторов остаются актуальными.

Не просто актуальными, а пересчитываются (ну или тянут за собой данные для пересчета)! Поэтому IndicatorRelease всегда имеет смысл делать, если 100% знаешь, что больше не понадобится. А это может произойти далеко до OnDeinit.

Например, если вызывать индикатор с каждый раз рэндомными входными параметрами, то никакого смысла не делать IndicatorRelease нет.

fxsaber:

Не просто актуальными, а пересчитываются (ну или тянут за собой данные для пересчета)! Поэтому IndicatorRelease всегда имеет смысл делать, если 100% знаешь, что больше не понадобится. А это может произойти далеко до OnDeinit.

Например, если вызывать индикатор с каждый раз рэндомными входными параметрами, то никакого смысла не делать IndicatorRelease нет.

Ну если Ваш алгоритм подразумевает постоянную смену параметров индикатора, то тогда да, Вы правы. Но если же на самом деле этого не происходит, то затраты машинных ресурсов на пересчёт многократно меньше, чем на создание "нового" индикатора + до этого был "убит" старый. Как я понял, именно эту мысль старался донести Ренат.
BlackTomcat:
Ну если Ваш алгоритм подразумевает постоянную смену параметров индикатора, то тогда да, Вы правы. Но если же на самом деле этого не происходит, то затраты машинных ресурсов на пересчёт многократно меньше, чем на создание "нового" индикатора + до этого был "убит" старый. Как я понял, именно эту мысль старался донести Ренат.
Да. Лучше всего сделать универсальное хранилище, как это реализовано разработчиками в MT4.
1...166016611662166316641665166616671668166916701671167216731674...3769
Новый комментарий