Ошибки, баги, вопросы - страница 3419

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

Все строго по документации:

"Перед выполнением операций (кроме операций присваивания) происходит преобразование в тип, имеющий наибольший приоритет, а перед операциями присваивания - в целевой тип"

Неужели такой сильнейший в пустоту расход вычислительных ресурсов в безобидной записи?

void OnStart()
{
  ushort ch = 0;
  
  ch = ch + 1; // ch = (ushort)((int)ch + 1); - Два преобразования.
  ch += 1;
  
  ch = ch + (ushort)1; // Ноль преобразований.
  ch += (ushort)1;
}


Такую хрень теперь писать, чтобы избегать ненужных вычислений?!

template <typename T>
void Inc( T &Value )
{
  Value += (T)1;
}
fxsaber #:

Неужели такой сильнейший в пустоту расход вычислительных ресурсов в безобидной записи?

Такую хрень теперь писать, чтобы избегать ненужных вычислений?!

Дополнительного расхода нет - потому что все все равно через int делается

void OnStart()
{
    short ch = 0;
    Print(typename(ch + ch));
}

Результат: int

Поэтому и предупреждения (2) выше были избыточны, и как Вы справедливо заметили - вместо простого кода приходится писать "хрень"

A100 #:

Поэтому и предупреждения выше были избыточны, и как Вы правильно заметили - вместо простого кода приходится писать "хрень"

К сожалению, не выйдет.

void OnStart()
{
  short ch = 5;
  
  Print(typename(ch + (short)1)); // int, похоже, и для ch+=1 будет преобразование.
  Print(typename(ch++)); // short
  
  // Никак не перевернуть знак без преобразования.
  Print(typename(-ch)); // int
  Print(typename((short)0 - ch)); // int
}
Возможно, typename формально все правильно выводит, а оптимизатор компилятора убирает эти пустые преобразования.
A100 #:

Дополнительного расхода нет - потому что все все равно через int делается

Получается, что short-числа работают медленнее int.
fxsaber #:
Получается, что short-числа работают медленнее int.

По крайней мере - не быстрее, а в ряде случаев не исключено, что и медленнее

fxsaber #:
Получается, что short-числа работают медленнее int.
Это уже вопрос для тестирования и, возможно, помещения в Вашу тему (https://www.mql5.com/ru/forum/170952)

Итоговый пример: 

void OnStart()
{
    short ch = 10;
    Print(typename(ch + 32767));//(*)//Результат: int
          ch =     ch + 32767;  //(1)//нормально
          ch = int(ch)+ 32767;  //(2)//Warning: possible loss of data due to type conversion from 'int' to 'short'
          ch =     ch + 32768;  //(3)//Warning: possible loss of data due to type conversion from 'int' to 'short'
}

Пусть Разработчики проверят разницу между (1),(2),(3) c учетом (*) и того, что:

"Типы данных char, uchar, short и ushort в операциях безусловно приводятся к типу int"

fxsaber #:
Получается, что short-числа работают медленнее int.

Все челочисленные типы ниже 32 бит в выражениях преобразуются к инту (32 бит) безусловно, даже если в выражении не участвует int. По-моему, это даже в документации написано

Ошибка при компиляции: 
class A {
static enum E { e } a; //Error: 'E' - enumeration cannot have modifiers
};
В последних выпусках появилось много Warning (и с каждым выпуском все новые и новые появляются), которых раньше не было, например: 
void OnStart()
{
    uint i =  -1;   //(1)
    if ( i == -1 ); //(2)//Warning: sign mismatch
}

Но если во (2) случае warning, то и в (1) тоже должен быть

С такой заботой о пользователе код превращается в трудночитаемую кашу

Предлагаю вернуть все как было - только необходимым минимум Warning

1...341234133414341534163417341834193420342134223423342434253426...3769
Новый комментарий