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

[fxsaber]

A100 #:

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

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

[A100]

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

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

[Sergey Gridnev]

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

Это уже вопрос для тестирования и, возможно, помещения в Вашу тему (https://www.mql5.com/ru/forum/170952)

[A100]

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

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"

[Slava]

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

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

[A100]

Ошибка при компиляции:

class A {
static enum E { e } a; //Error: 'E' - enumeration cannot have modifiers
};

[A100]

В последних выпусках появилось много Warning (и с каждым выпуском все новые и новые появляются), которых раньше не было, например:

void OnStart()
{
    uint i =  -1;   //(1)
    if ( i == -1 ); //(2)//Warning: sign mismatch
}

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

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

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

[fxsaber]

A100 #:

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

Мне нравится именно так, как сейчас.

[Maxim Kuznetsov]

A100 #:
В последних выпусках появилось много Warning, которых раньше не было, например:

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

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

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

imho в первом случае он (warning) просто обязан быть

это про второй бабушка надвое, потому что может быть внутри шаблонов/дефайнов и наверное не всегда можно вывести тип.

Но в первом - слева беззнаковый тип, справа отрицательный литерал. Там должна быть ругать матом - там всё сразу несошлось

[A100]

Maxim Kuznetsov #:

imho в первом случае он (warning) просто обязан быть

это про второй бабушка надвое, потому что может быть внутри шаблонов/дефайнов и наверное не всегда можно вывести тип.

Но в первом - слева беззнаковый тип, справа отрицательный литерал. Там должна быть ругать матом - там всё сразу несошлось

О том и речь, что там где не нужно - он появился, а там где нужно - нет. Какой тогда вообще смысл в их добавлении?!