Глюк в MetaEditorMT5 - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А теперь прогоните цикл до 9 индекса. Что вы видите, данные перезаписались?
Нет. Массив накопил данные во всех десяти индексах и больше запись не идёт (не пускает условие цикла for(int i=size_arr_bid; i<10; i++) ).
Такое поведении статического массива я считаю ошибкой. Этот статический массив double arr_bid[10] (объявленный без static) должен как и любая локальная переменная пересоздаваться.Я так пишу и другие так же пишут, чтобы переменная была в блоке для быстрого доступа и до обновы проблем не было
Нет. Массив накопил данные во всех десяти индексах и больше запись не идёт (не пускает условие цикла for(int i=size_arr_bid; i<10; i++) ).
Владимир, ты с ним не в те дебри полез - он проверяет возврат на false и на true одновременно. Получая true он всё равно выводит алерт что значения не получены.
Нет. Массив накопил данные во всех десяти индексах и больше запись не идёт (не пускает условие цикла for(int i=size_arr_bid; i<10; i++) ).
Такое поведении статического массива я считаю ошибкой. Этот статический массив double arr_bid[10] (объявленный без static) должен как и любая локальная переменная пересоздаваться.Да, норм, спс. Он у меня изначально был динамическим, не этот, другой для баров и до обновы все было норм, значит надо дописать везде обнуление
Да, норм, спс. Он у меня изначально был динамическим, не этот, другой для баров и до обновы все было норм, значит надо дописать везде обнуление
Я создам заявку в СервисДеск по поводу поведения статического массива double arr_bid[10] (объявленный без static) и объявленного как локальная переменная.
Создана заявка: Статический массив double arr_bid[10] (объявленный без static) ведёт себя как static
Создана заявка: Статический массив double arr_bid[10] (объявленный без static) ведёт себя как static
Спасибо за обращение в сервисдеск, ответили на заявку.
Подытожу здесь.
Локальные переменные функции необходимо явно инициализировать, это касается и массивов (если они не динамические).
Если переменные не инициализируются - ждите трудноуловимых ошибок, такие коды, с большой долей вероятности, будут вести себя по разному при компиляции под отладку и релиз (из-за разных уровней оптимизации кода).
То, что в приведённом примере, массив arr_bid ведёт себя как статический - особенность конкретного кода.
Дело в том, что локальные переменные функций располагаются в стеке, при вложенных вызовах они лежат в стеке последовательно, согласно порядку вызовов функций (стек вызовов).
В приведённом примере, для функции TestFunction (с якобы статическим массивом arr_bid), для локальных переменных, на стеке выделяется одно и тоже место, т.е. элементы массива arr_bid "лежат" в той же памяти, поэтому и кажется, что он статический.
Фактически же, массив arr_bid содержит мусор (данные на стеке могли оказаться какими угодно), т.к. массив не был проинициализирован корректно (в примере инициализаруется только часть его элементов).
Пару дней назад была обнова MT5 и возник глюк (то 3-й, то 4-й индекс, 7-й, в массиве проходит битым), записывается в цикле верно, а во втором цикле засада, или это только в MetaEditor, или сливы депозитов
а что за ерунда в строке 146?
картинку комментировать сложно, научитесь уже вставлять код
Спасибо за обращение в сервисдеск, ответили на заявку.
Подытожу здесь.
Локальные переменные функции необходимо явно инициализировать, это касается и массивов (если они не динамические).
Если переменные не инициализируются - ждите трудноуловимых ошибок, такие коды, с большой долей вероятности, будут вести себя по разному при компиляции под отладку и релиз (из-за разных уровней оптимизации кода).
То, что в приведённом примере, массив arr_bid ведёт себя как статический - особенность конкретного кода.
Дело в том, что локальные переменные функций располагаются в стеке, при вложенных вызовах они лежат в стеке последовательно, согласно порядку вызовов функций (стек вызовов).
В приведённом примере, для функции TestFunction (с якобы статическим массивом arr_bid), для локальных переменных, на стеке выделяется одно и тоже место, т.е. элементы массива arr_bid "лежат" в той же памяти, поэтому и кажется, что он статический.
Фактически же, массив arr_bid содержит мусор (данные на стеке могли оказаться какими угодно), т.к. массив не был проинициализирован корректно (в примере инициализаруется только часть его элементов).
Во-во, а некоторые почему-то думают, что Господь им локальные переменные обнулит. Наверное не понимают, что локальные переменные располагаются на стеке и там может быть что угодно от прошлых операций, в т.ч. вызовов других функций.
Спасибо за обращение в сервисдеск, ответили на заявку.
Подытожу здесь.
Локальные переменные функции необходимо явно инициализировать, это касается и массивов (если они не динамические).
Если переменные не инициализируются - ждите трудноуловимых ошибок, такие коды, с большой долей вероятности, будут вести себя по разному при компиляции под отладку и релиз (из-за разных уровней оптимизации кода).
То, что в приведённом примере, массив arr_bid ведёт себя как статический - особенность конкретного кода.
Дело в том, что локальные переменные функций располагаются в стеке, при вложенных вызовах они лежат в стеке последовательно, согласно порядку вызовов функций (стек вызовов).
В приведённом примере, для функции TestFunction (с якобы статическим массивом arr_bid), для локальных переменных, на стеке выделяется одно и тоже место, т.е. элементы массива arr_bid "лежат" в той же памяти, поэтому и кажется, что он статический.
Фактически же, массив arr_bid содержит мусор (данные на стеке могли оказаться какими угодно), т.к. массив не был проинициализирован корректно (в примере инициализаруется только часть его элементов).
Спасибо за ответ.
Подитожу, что если используется массив (не динамический) и потом будет обход НЕ ПО ВСЕМ ИНДЕКСАМ массива, тогда АРХИВАЖНО проводить инициализацию, дабы не подхватить со стека прежние данные.