Ошибки, баги, вопросы - страница 493
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
не спорю
а так
есть округление все равно пишет, так и надо ?
Разработчикам.
Случайно зациклил обработку тиков в эксперте, после чего появилась критическая ошибка о переполнении стека.
Все проблема в том что в сообщении нет конкретной информации о том что и где конкретно произошло.
Предлагаю уточнить текст данного сообщения, если возможно хочется отловить подобные проблемы (такие как вызов метода класса из вызываемого метода) на стадии компиляции.
Причина, почему iCustom() присваивает произвольные значения тем ячейкам буфера, которые в реальности ничем не заполнялись, мне не ясна, как и то, почему этого никак нельзя избежать.
Предполагаю, что это как-то связано с распределением памяти под соответствующий массив данных индикаторного буфера.
Подобная работа iCustom(), когда невозможно определить происхождение и истинность данных, мне кажется недопустимой и создающей дополнительные риски для пользователя.
Если iCustom() и так присваивает ячейкам буфера произвольные, не соответствующие реальным значения,
то почему бы не ему не присваивать этим ячейкам значение, равное Empty_Value, как это реализовано в МТ4.
Тогда по крайней мере был бы понятен их статус.
Разработчикам.
..........., если возможно хочется отловить подобные проблемы (такие как вызов метода класса из вызываемого метода) на стадии компиляции.
Я против. Это непомерно усложнит компилятор, а значит сделает его менее надёжным.
Отслеживать некорректную рекурсию - дело программиста.
А вот в сообщении об ошибке выдать имя функции переполнившей стек - это да, хотелось бы.
Никто, кроме автора, не может решить, чем должны быть заполнены неиспользуемые значения буфера. Вы говорите, Empty_Value, а мне, например, надо, что там был 0, или ещё что-то. Какое Вам нужно значение, тем и инициализируйте.
Все верно и логично. Но проблема в том и состоит, что ячейки буфера, которые пользователь ничем (!) не заполнял функция iCustom() на свое усмотрение периодически забивает произвольным мусором. Разве так должно быть?
Я против. Это непомерно усложнит компилятор, а значит сделает его менее надёжным.
Отслеживать некорректную рекурсию - дело программиста.
А вот в сообщении об ошибке выдать имя функции переполнившей стек - это да, хотелось бы.
Да, мы специально не усложняем рабочий движок (он ведь нативный 32/64) метаинформацией.
Рекурсию обычно легко отловить - она напрямую зависит от объема локальных переменных, а таких мест в программе бывает исключительно мало.
Все верно и логично. Но проблема в том и состоит, что ячейки буфера, которые пользователь ничем (!) не заполнял функция iCustom() на свое усмотрение периодически забивает произвольным мусором. Разве так должно быть?
Если кастомный индикатор не заполняет корректно свой буфер - значит именно этот кастомный индикатор и виноват.
А если этот кастомный индикатор отдает наружу свои результаты через iCustom, то он виноват вдвойне, так как вводит в заблуждение пользователей.
Если кастомный индикатор не заполняет корректно свой буфер - значит именно этот кастомный индикатор и виноват.
А если этот кастомный индикатор отдает наружу свои результаты через iCustom, то он виноват вдвойне, так как вводит в заблуждение пользователей.
Если кастомный индикатор не заполняет корректно свой буфер - значит именно этот кастомный индикатор и виноват.
А если этот кастомный индикатор отдает наружу свои результаты через iCustom, то он виноват вдвойне, так как вводит в заблуждение пользователей.
Я все-таки не понимаю, что мешает делать программу не только эффективной, но и удобной? Если я правильно помню, аргументация за отсутствие встроенной инициализации индикаторных буферов в пятерке состоит в оптимизации по скорости. При этом разработчик индикатора вынужден сам кодить те самые строчки по инициализации ("нулями"), которые раньше в четверке выполняло ядро. Так что результирующая эффективность вроде не становится лучше, а удобство страдает. Но раз уж зачем-то решено было так сделать, то почему не сделать опционально? Т.е. можно было ввести еще одно #property, указывающее нужно ли инциализировать буфера автоматически.
В качестве резюме повторю мысль, которую уже как-то высказывал: задача платформы, каковой является МТ, максимально оградить пользователя (программиста) от возможных "граблей".
Все верно и логично. Но проблема в том и состоит, что ячейки буфера, которые пользователь ничем (!) не заполнял функция iCustom() на свое усмотрение периодически забивает произвольным мусором. Разве так должно быть?
Вапчета общепринятое правило : инициализация массивов на усмотрение юзера. Непроинициализированный массив содержит случайные значения из распределённой для него памяти. У юзера могут быть разумные соображения не инициализировать массив без надобности (например для экономии времени). Я иногда таким образом время экономлю, если уверен, что не буду этот мусор читать и "кушать" прежде чем там появится реальная информация.
Злого умысла на стороне MQ не вижу. Скорее буду возражать, если они "для профилактики" начнут притормаживать мои программы.