Новый синтаксис MQL4 - страница 3

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

У меня вопрос по поводу типов переменных, int, uint, char, short ushort и т.д. Новый компилятор выдает предупреждения о возможной потере данных из-за преобразования типов, поэтому лучше всего;

a) использовать тот тип, который лучше всего соответствует требованиям переменной или,

b) избегать преобразования между типами и поэтому использовать int для всего. (ну, для всего, что не требует плавающей точки).

 
SDC:

У меня вопрос по поводу типов переменных, int, uint, char, short ushort и т.д., является ли лучшей практикой;

a) использовать тот тип, который лучше всего соответствует требованиям переменной или

b) избегать конвертации между типами и поэтому использовать int для всего. (ну, для всего, что не требует плавающей точки).

Если вам нужна беззнаковая длина, то int не подойдет... используйте правильный тип и явное преобразование типа. IMO
 

Под явным преобразованием типов вы подразумеваете, что преобразование выполняется перед любыми вычислениями между различными типами?

 
RaptorUK:
Если вам нужен беззнаковый long, то int не подойдет... используйте правильный тип и явное преобразование типа. IMO

Согласитесь.
 
SDC:

Под явным преобразованием типов вы подразумеваете, что преобразование выполняется перед любыми вычислениями между различными типами?

См. здесь: https: //www.mql5.com/en/docs/basis/types/casting
 

Хорошая статья, спасибо angevoyageur Я прочитаю ее как следует, когда вернусь домой с работы.

 
SDC:

Под явным приведением типа вы имеете в виду, что преобразование должно выполняться перед любыми вычислениями между различными типами?

Нет, я имею в виду, что вы можете преобразовать ulong в int следующим образом...

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

Хорошо, да, я так и думал, что вы имели в виду.

Только я не спрашивал об ulong. Мне редко, если вообще когда-либо, придется работать с такими большими значениями, которые не может вместить 32-битное целое число. Я даже не знаю, как сказать, какое число может хранить 64-битное целое число, lol...

Возможно, мне следовало быть более конкретным, у меня не было времени сегодня утром, чтобы написать свой вопрос должным образом, но теперь, когда я дома, я это сделаю.

В старом mql4 мы использовали целое число для всего. Мы писали for(int i=0; i<100; i++) Нам не нужны отрицательные значения, и нам не нужно значение больше 100, поэтому мы можем использовать uchar для этого. Значит ли это, что именно так мы и должны поступать?

Когда я смотрю на код других программистов, кажется, что многие из них используют 32-битные целочисленные типы. Есть ли для этого веская причина? Что они знают такого, что мне еще предстоит узнать? Использование наименьших типов переменных в программе создает головную боль из-за проблем с типизацией без какой-либо причины, кроме как немного меньшего размера файла? Или это экономит много оперативной памяти? Можно ли считать, что если значение одного типа может быть адаптировано к другому типу, то это можно делать? Использует ли приведение типов между различными типами намного больше CPU, чем использование одного типа?

Обновление: Я изучал этот вопрос и прочитал ответ на аналогичный вопрос на stackoverflow.com

"С точки зрения производительности, int быстрее почти во всех случаях. Процессор создан для эффективной работы с 32-битными значениями.

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

Чтобы записать байт, он должен прочитать конечный 32-битный блок, перезаписать младшие 8 бит желаемым значением байта и снова записать весь 32-битный блок.

С точки зрения пространства, конечно, вы экономите несколько байт, используя меньшие типы данных. Так что если вы создаете таблицу с несколькими миллионами строк, то более короткие типы данных, возможно, стоит рассмотреть. (И то же самое может быть хорошей причиной, почему вы должны использовать меньшие типы данных в своей базе данных).

И с точки зрения корректности, int не так легко переполняется. Что если вы думаете, что ваше значение поместится в байт, а потом в какой-то момент в будущем какое-то безобидное на вид изменение в коде приведет к тому, что в нем будут храниться большие значения?

Это некоторые из причин, по которым int должен быть вашим типом данных по умолчанию для всех интегральных данных. Используйте байт только в том случае, если вы действительно хотите хранить машинные байты. Используйте шорт, если вы имеете дело с форматом файла, протоколом или чем-то подобным, который действительно определяет 16-битные целочисленные значения. Если вы просто имеете дело с целыми числами вообще, делайте их ints".

 
SDC:

Да, я так и думал, что вы имели в виду.

Только я не спрашивал об ulong. Мне редко, если вообще когда-либо, придется работать с такими большими значениями, которые не может вместить 32-битное целое число. Я даже не знаю, как сказать, какое число может хранить 64-битное целое число...

Возможно, мне следовало быть более конкретным, у меня не было времени сегодня утром, чтобы написать свой вопрос должным образом, но теперь, когда я дома, я это сделаю.

В старом mql4 мы использовали целое число для всего. Мы писали for(int i=0; i<100; i++) Нам не нужны отрицательные значения, и нам не нужно значение больше 100, поэтому мы можем использовать uchar для этого. Значит ли это, что именно так мы и должны поступить?

uchar - беззнаковый символ, зачем использовать его в цикле? Это не имеет смысла... используйте int. Вы будете работать с улонгами, вот что такое новое время даты ... и когда вы набираете текст, не думая об этом, в будущем вы получите предупреждение ... смиритесь с предупреждением или проигнорируйте его. Не надейтесь на лучшее, делайте то, что вы делаете сейчас, учитесь и понимайте.

То, что вы разместили на stackoverflow, имеет смысл для меня, я думаю, это хороший совет.

 
SDC: Использует ли приведение типов между различными типами намного больше CPU, чем использование одного и того же типа?

Между разными размерами используется больше процессора, но не намного больше. Просто разные инструкции, как упомянутые 32-битные fetch, isolate, operate, place, write, при модификации char в структуре. Так же, как умножение на 0.5 использует немного меньше CPU, чем деление на 2.0.

Экономия 16 бит на элемент массива не имеет смысла на GB машинах, я делал это, когда реализовывал приложение, базу данных, GUI (vt100) в 8 KB (sic.) Переход на 64 бита на (для всего) не будет иметь смысла, пока 128 битные платформы не станут обычным явлением.

Между знаковыми и беззнаковыми нет никакой разницы. Это просто присваивание, никакие биты не меняются. Разница заключается в коде, который использует переменную. Например, A[index] делает Address(a) + index * sizeof(a[0]), где плюс - знаковое или беззнаковое сложение.

Для ясности кодирования я бы использовал uint для индексации массивов, так как A[-1] не имеет смысла, но тогда обратный отсчет проблематичен FOR(uint iA=n; iA >= 0; iA--){} iA>=0 всегда истинно.

Используйте int (или uint), если это не требуется по другим причинам.
123456
Новый комментарий
Причина обращения: