possible loss of data due to type conversion mql4 как исправить
Помогите избавиться от предупреждений
Добрый день имея в коде: #property strict
Прошу вас написать как избавиться от ряда предупреждений:
2) implicit conversion from ‘string’ to ‘number’
3) implicit conversion from ‘string’ to ‘number’
Добрый день имея в коде: #property strict
Прошу вас написать как избавиться от ряда предупреждений:
2) implicit conversion from ‘string’ to ‘number’
3) implicit conversion from ‘string’ to ‘number’
Добрый день имея в коде: #property strict
Прошу вас написать как избавиться от ряда предупреждений:
2) implicit conversion from ‘string’ to ‘number’
3) implicit conversion from ‘string’ to ‘number’
Why error «possible loss due to conversion», and how to solve this?
I have written this small function which helps any programs to do the normalize of prices (without having to re-type the long normalize command), but it keeps giving this error. How can i solve this?
the error is: possible loss of data due to type conversion tstEA.mq5 78 12
if theres any suggestion or work around to this? Thx!
Update: Now I do this (as below), and the error disappears. but is my solution below ok? Will it have any effects later, is what i am worried.
It isn’t an error. It’s just a warning.
I think this topic helps you
It isn’t an error. It’s just a warning.
I think this topic helps you
Yes, i read 70-80% before, thats how I know to do that thing (int).
Thanks for letting me know its not error. Its a huge relief to me. This topic is solved, thanks to your reply.
Very old topic but still some questions.
With (int) I prevent the » possible loss of data due to type conversion». The data type of iVolume is long and therefore takes 8 byte. Does this operation cause it to take only 4 bytes? Or does this additional code (int) increase the memory size. In other words which of these has the best performance: a) or b)?
There is no difference between a) and b) except for the compiler warning.
‘sum’ remains an int; it can’t change.
The compiler is warning you that the long value from iVolume will be put into an int, as there is no other choice. It warns you because you haven’t explicitly asked for this to happen (but it is going to happen nevertheless).
By typecasting, you are instructing it to put the long value into an int. As you have done this explicitly, there is no need for the warning.
Possible loss of data due to type conversion.
Wondering if someone can assist with troubleshooting an EA that I am currently developing.
I am getting the following error: Possible loss of data due to type conversion.
At the following line:
I have managed to get «past» this issue by swapping OrderOpenTime(); to (int)OrderOpenTime(); but I am noticing during forward testing that after a few entries it stops entering further positions for no reason
Could this be part of the problem? If so, can someone help?
Do you really expect an answer? There are no mind readers here and our crystal balls are cracked. Always post all relevant code (using Code button).
How To Ask Questions The Smart Way. 2004
Be precise and informative about your problem
We can’t possibly know what tradelist is.
Unless you need to sort it (ArraySort)(by time) why do you need to store anything but tickets?
Do you really expect an answer? There are no mind readers here and our crystal balls are cracked. Always post all relevant code (using Code button).
How To Ask Questions The Smart Way. 2004
Be precise and informative about your problem
We can’t possibly know what tradelist is.
Unless you need to sort it (ArraySort)(by time) why do you need to store anything but tickets?
Apologies for this, please find below the full code:
My main problem is there it’s supposed to enter a position after every signal, which it does but after a certain period (no consitent) it stops and doesn’t enter again, sometimes 10 trades sometimes 20 it depends
I am trying to understand why it doesn’t enter anymore, and I know I had an alert about «Possible loss of data due to type conversion» with the following line:
I resolved this by changing it to the following:
But I am still having the same problem where the positions stop stacking after a variable X amount of entries
Что не так? possible loss of data due to type conversion
Написал декодирование магика, а компиляция ругается. Что ей не нравится?
Тем не менее отрабатывает почти правильно:
Ошибку нашёл. Работает.
Но предупреждения остались. Что ему не нравится?
Все верно не нравится.
num_symbol = StringToInteger (str_symb); // матерится possible loss of data due to type conversion
Блиииин. Голова два уха ))))))))))
У меня вроде с типами все ок, но ругается:
А вот так нормально:
где DIGIT_pair1 должен быть int. Короче не знаю, что сказать. Так всё закручено))
Помогите исправить possible loss of data due to type conversion:
string LowerCase(string value)
for (i = 0; i = 65 && n + 32); // вот тут possible loss of data due to type conversion именно где подчёркнуто
string UpperCase(string value)
for (i = 0; i = 97 && n // вот тут possible loss of data due to type conversion именно где подчёркнуто
У меня вроде с типами все ок, но ругается:
А вот так нормально:
где DIGIT_pair1 должен быть int. Короче не знаю, что сказать. Так всё закручено))
Где то было, что целые числа упрощенно представлены и требуют явного приведения типа или изначально правильного.
других путей не нашел, или явное приведение или изначально правильный тип целого.
Типичные ошибки в программах на MQL4 и методы их устранения
Введение
При использовании новой версии компилятора языка MQL4 некоторые старые программы могут выдавать ошибки.
В старой версии компилятора во избежание критического завершения программ многие ошибки обрабатывались средой исполнения и не приводили к остановке работы. Например, деление на ноль или выход за пределы массива являются критическими ошибками и обычно приводят к аварийному завершению. Проявляются такие ошибки лишь в некоторых состояниях при определенных значениях переменных, однако о таких ситуациях следует знать и корректно их обрабатывать.
Новый компилятор позволяет обнаружить реальные или потенциальные источники ошибок и повысить качество кода.
В этой статье мы рассмотрим возможные ошибки, возникающие при компиляции старых программ, и методы их устранения.
1. Ошибки компиляции
При наличии ошибок в коде программа не может быть скомпилирована.
Для полного контроля всех ошибок рекомендуется использовать строгий режим компиляции, который устанавливается директивой:
Этот режим значительно упрощает поиск ошибок.
1.1. Идентификатор совпадает с зарезервированным словом
Если наименование переменной или функции совпадает с одним из зарезервированных слов:
то компилятор выводит сообщения об ошибках:
Рис.1. Ошибки «unexpected token» и «name expected»
Для исправления данной ошибки нужно исправить имя переменной или функции.
1.2. Специальные символы в наименованиях переменных и функций
Если наименования переменных или функций содержат специальные символы ($, @, точка):
то компилятор выводит сообщения об ошибках:
Рис.2. Ошибки «unknown symbol» и «semicolon expected»
Для исправления данной ошибки нужно скорректировать имена переменных или функций.
1.3. Ошибки использования оператора switch
Старая версия компилятора позволяла использовать любые значения в выражениях и константах оператора switch:
В новом компиляторе выражения и константы оператора switch должны быть целыми числами, поэтому при использовании подобных конструкций возникают ошибки:
Рис.3. Ошибки «illegal switch expression type» и «constant expression is not integral»
В таких случаях можно использовать явные сравнения численных значений, например:
1.4. Возвращаемые значений функций
Все функции, кроме void, должны возвращать значение объявленного типа. Например:
При строгом режиме компиляции (strict) возникает ошибка:
Рис.4. Ошибка «not all control paths return a value»
В режиме компиляции по умолчанию компилятор выводит предупреждение:
Рис.5. Предупреждение «not all control paths return a value»
Если возвращаемое значение функции не соответствует объявлению:
то при строгом режиме компиляции возникает ошибка:
Рис.6. Ошибка «function must return a value»
В режиме компиляции по умолчанию компилятор выводит предупреждение:
Для исправления таких ошибок в код функции нужно добавить оператор возврата return c возвращаемым значением соответствующего типа.
1.5. Массивы в аргументах функций
Массивы в аргументах функций теперь передаются только по ссылке.
Данный код при строгом режиме компиляции (strict) приведет к ошибке:
Рис.8. Ошибка компилятора «arrays passed by reference only»
В режиме компиляции по умолчанию компилятор выводит предупреждение:
Рис.9. Предупреждение компилятора «arrays passed by reference only»
Для исправления таких ошибок нужно явно указать передачу массива по ссылке, добавив префикс & перед именем массива:
Следует отметить, что теперь константные массивы ( Time[], Open[], High[], Low[], Close[], Volume[]) не могут быть переданы по ссылке. Например, вызов:
вне зависимости от режима компиляции приводит к ошибке:
Для устранения подобных ошибок нужно скопировать необходимые данные из константного массива:
2. Ошибки времени выполнения
Ошибки, возникающие в процессе исполнения кода программы принято называть ошибками времени выполнения (runtime errors). Такие ошибки обычно зависят от состояния программы и связаны с некорректными значениями переменных.
Например, если переменная используется в качестве индекса элементов массива, то ее отрицательные значения неизбежно приведут к выходу за пределы массива.
2.1. Выход за пределы массива (Array out of range)
Эта ошибка часто возникает в индикаторах при обращении к индикаторным буферам. Функция IndicatorCounted() возвращает количество баров, неизменившихся после последнего вызова индикатора. Значения индикаторов на уже рассчитанных ранее барах не нуждаются в пересчете, поэтому для ускорения расчетов достаточно обрабатывать только несколько последних баров.
Большинство индикаторов, в которых используется данный способ оптимизации вычислений, имеют вид:
Часто встречается некорректная обработка случая counted_bars==0 (начальную позицию limit нужно уменьшить на значение, равное 1 + максимальный индекс относительно переменной цикла).
Также следует помнить о том, что в момент исполнения функции start() мы можем обращаться к элементам массивов индикаторных буферов от 0 до Bars()-1. Если есть необходимость работы с массивами, которые не являются индикаторными буферами, то их размер следует увеличить при помощи функции ArrayResize() в соответствии с текущим размером индикаторных буферов. Максимальный индекс элемента для адресации также можно получить вызовом ArraySize() с одним из индикаторных буферов в качестве аргумента.
2.2. Деление на ноль (Zero divide)
Ошибка «Zero divide» возникает в случае, если при выполнении операции деления делитель оказывается равен нулю:
При выполнении данного скрипта во вкладке «Эксперты» возникает сообщение об ошибке и завершении работы программы:
Рис.11. Сообщение об ошибке «zero divide»
Обычно такая ошибка возникает в случаях, когда значение делителя определяется значениями каких-либо внешних данных. Например, если анализируются параметры торговли, то величина задействованной маржи оказывается равна 0 если нет открытых ордеров. Другой пример: если анализируемые данные считываются из файла, то в случае его отсутствия нельзя гарантировать корректную работу. По этой причине желательно стараться учитывать подобные случаи и корректно их обрабатывать.
В результате критической ошибки не возникает, но выводится сообщение о некорректном значении параметра и работа завершается:
Рис. 12. Сообщение о некорректном значении делителя
2.3. Использование 0 вместо NULL для текущего символа
В старой версии компилятора допускалось использование 0 (нуля) в качестве аргумента в функциях, требующих указания финансового инструмента.
Например, значение технического индикатора Moving Average для текущего символа можно было запрашивать следующим образом:
В новом компиляторе для указания текущего символа нужно явно указывать NULL:
Кроме того, текущий символ и период графика можно указать при помощи функций Symbol() и Period().
2.4. Строки в формате Unicodе и их использование в DLL
Строки теперь представляют собой последовательность символов Unicode.
Следует учитывать этот факт и использовать соответствующие функции Windows. Например, при использовании функций библиотеки wininet.dll вместо InternetOpenA() и InternetOpenUrlA () следует вызывать InternetOpenW() и InternetOpenUrlW().
В MQL4 изменилась внутренняя структура строк (теперь она занимает 12 байт), поэтому при передаче строк в DLL следует использовать структуру MqlString:
2.5. Совместное использование файлов
В новом MQL4 при открытии файлов необходимо явно указывать флаги FILE_SHARE_WRITE и FILE_SHARE_READ для совместного использования.
В случае их отсутствия файл будет открыт в монопольном режиме, что не позволит больше никому его открывать, пока он не будет закрыт монополистом.
Например, при работе с оффлайновыми графиками требуется явно указывать флаги совместного доступа:
Подробности можно найти в статье в статье «Оффлайновые графики и новый MQL4«.
2.6. Особенность преобразования datetime
Следует иметь ввиду, что преобразование типа datetime в строку теперь зависит от режима компиляции:
Например, попытка работы с файлами, имя которых содержит двоеточие, приведет к ошибке.
3. Предупреждения компилятора
Чистый код не должен содержать предупреждений.
3.1. Пересечения имен глобальных и локальных переменных
Если на глобальном и локальном уровнях присутствуют переменные с одинаковыми именами:
то компилятор выводит предупреждение и укажет номер строки, на которой объявлена глобальная переменная:
Рис.13. Предупреждение «declaration of ‘%’ hides global declaration at line %»
Для исправления таких предупреждений нужно скорректировать имена глобальных переменных.
3.2. Несоответствие типов
В новой версии компилятора в ведена операция приведения типов.
В строгом режиме компиляции при несоответствии типов компилятор выводит предупреждения:
Рис.14. Предупреждения «possible loss of data due to type conversion» и «implicit conversion from ‘number’ to ‘string’
В данном примере компилятор предупреждает о возможной потере точности при присвоении различных типов данных и неявном преобразовании типа int в string.
Для исправления нужно использовать явное приведение типов:
3.3. Неиспользуемые переменные
Наличие переменных, которые не используются в коде программы (лишние сущности) не является хорошим тоном.
Сообщения о таких переменных выводятся вне зависимости от режима компиляции:
Рис.15. Предупреждения «variable ‘%’ not used’
Для исправления нужно убрать неиспользуемые переменные из кода программы.
Выводы
В статье рассмотрены типичные проблемы, с которыми могут столкнуться программисты при компиляции старых программ, содержащих ошибки.
Во всех случаях при отладке программ рекомендуется использовать строгий режим компиляции.