Ошибки, баги, вопросы - страница 3558
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну Вы же пишете, а значит - нет бана.
Если видите в профиле бан, перезагрузите роутер - наверняка у него динамический IP, и просто текущий попал на забаненный адрес. После перезагрузки роутера, IP сменится, и бана не будет.
Да, роутер с динамик. айпи. Спасибо.
Такой тут ещё впрос. достал я советник, закинул в тестер мт5, он долго думал потом сказал инит файлед.. Но он рабочий. Перекинул на другой комп - работает всё ок. Перегррузил свой- тоже работает, они по ходу как то связаны с оперативной памятью или нет? Если её очистить под 0 то тоже ошибка исчезает.
Правильно ли я понимаю, что при вызове метода withPtr() указатель будет проверен количество раз, равное размеру массива m_a.x[], а при вызове метода withRef() указатель будет проверен только 1 раз?
Полный код прикрепил в виде скрипта. Скрипт сравнивает скорость выполнения методов withPtr() и withRef().
Для десяти миллионов обращений withRef() показывает примерно пятикратное ускорение (режим компиляции: maximum optimization):
Вы использовали лайфхак преобразования указателя в объект.
Тем самым обнулив проверку указателя на каждой итерации цикла. Выглядит, как ошибка языка, приводящая к ускорению.
Это произошло из-за изменения в файле данных, которое привело к чтению за конец файла.
Не понял, т.е. файл слишком большой и не хватило памяти ОЗУ? По факту файл не большой и уменьшается в процессе работы скрипта.
Вот функция чтения - раньше не замечал подобных сообщений - активно использую не менее года.
Не понял, т.е. файл слишком большой и не хватило памяти ОЗУ? По факту файл не большой и уменьшается в процессе работы скрипта.
Вот функция чтения - раньше не замечал подобных сообщений - активно использую не менее года.
Это именно проблема. Извините, но я не буду проверять ваш код, у меня нет на это времени.
Разработчики MetaQuotes знают о сообщении «VirtualAlloc», и я полагаю, что они улучшат его в будущем. Но проблемы можно избежать.
Но проблемы можно избежать.
Как избежать?
, они по ходу как то связаны
Они связаны против хода.
Вы использовали лайфхак преобразования указателя в объект. Выглядит, как ошибка языка, приводящая к ускорению.
Это не лайфхак, а задокументированная возможность
https://www.mql5.com/ru/docs/basis/types/object_pointers
Это не лайфхак, а задокументированная возможность
Ошибка в документации. С template такое не прокатит, например.
Тем самым обнулив проверку указателя на каждой итерации цикла. Выглядит, как ошибка языка, приводящая к ускорению.
По логике вещей, указатель все равно будет единократно проверен при преобразовании.
Следующий тест показывает, что при попытке удалить объект внутри метода, он будет удален только после выхода из метода (утечки памяти нет по итогу):
Ошибка в документации. С template такое не прокатит, например.
Я не считаю, что это ошибка. Постом выше я показал, что сломать эту механику не получится даже при желании.
Шаблонами не пользуюсь, не могу ничего сказать.