Type conversions в CodeVision, unsigned char->float Опции

[Gogan]

Есть вот такой проргамный код для АВР(например):

unsigned char a = 100;
float b = 20;

далее в программе

if( b < -a ){...}

так вот оказывается, в таком случаее условие выполняется.
Если кастовать вот так :

if( b < - (int) a ) {...}

тогда все ок. Объясните почему? Я не могу понять, что с чем сравнивается, если не кастовать, и почему так происходит?

[ReAl]

unsigned char a = 100;
float b = 20;

далее в программе

if( b < -a ){...}

так вот оказывается, в таком случаее условие выполняется.
Если кастовать вот так :

if( b < - (int) a ) {...}

тогда все ок. Объясните почему? Я не могу понять, что с чем сравнивается, если не кастовать, и почему так происходит?

На мой взгляд, компилятор не прав. Согласно стандарту С он должен оба эти if-а обрабаотывать одинаково и так, как второй. Есть такая штука, как integer promotion rules (integer promotions), согласно им любой целочисленный тип, который меньше int-а, должен приводиться к int перед вычислением выражений. Даже для

Код

char a,b,c;
a = b + c;

- привести к int, сложить, результат усечь и присвоить a.
Это требования к "абстрактной машине", дальше можно дать свободу и не делать приведение к int, но только в случае, если от такого неделания результат не изменится.
В данном случае -a это уже подвыражение с унарным минусом, перед его вычислением компилятору надо было привести a к int (что во втором примере сделано вручную), потом применить минус, потом, согласно правилам автоматических преобразований типов, результат привести к float и сравнить.
Так что тут компилятор не имел права делать -a в пределах байта.

eeprom unsigned char edata[20][8]={{90,0,...},{}...};
unsigned int a;

далее в тексте
a=edata[0][0]+edata[0][1]<<8;

т.е. интегер хранится в двух первых байтах, сначала младший потом старший. Компилер выдал, что edata[0][1]<<8 получится в любом случае 0. Я переписал
a=(int)edata[0][0]+edata[0][1]<<8;

опять неправильно. Компилер не ругался, но результат был 90х256=23040. Правильным вариантом оказалось:
a=edata[0][0]+(int)edata[0][1]<<8;

Выбрось каку!!!
Правильный компилятор (соответствующий стандарту) во всех трёх приведённых тобой вариантах должен был дать одинаковый результат, впрочем, не тот, который ты ожидаешь
Приведение к int делать вообще не нужно, оно должно было быть сделано согласно integer promotions самим компилятором.
А вот дальше - у оператора сложения приоритет выше, чем у операции сдвига (с моей точки зрения, приоритет сдвигов должен бы быть между приоритетами *% и +-, но K&R когда-то решили иначе и стандарт есть стандарт), поэтому
a + b << 8;
должно вычисляться всегда как
( a + b ) << 8;

А то, что хотелось сделать, следует записывать как
a + ( b << 8 );


p.s. Не понимаю, как можно пользоваться компилятором, настолько не соответствующим стандарту...
Или он позиционируется как "компилятор С-подобного языка программирования" ???

[Палыч]

Приведение к int делать вообще не нужно, оно должно было быть сделано согласно integer promotions самим компилятором.

ISO9899 п.6.3.1.1 абз.2

The following may be used in an expression wherever an int or unsigned int may be used:
— An object or expression with an integer type whose integer conversion rank is less than the rank of int and unsigned int.
— A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

Так, должно или может быть сделано?

[ReAl]

ISO9899 п.6.3.1.1 абз.2
Так, должно или может быть сделано?

Могут перечисленные типы применяться в тех местах, где может применяться int или unsigned int
Приведение должно быть сделано к int, если он может вместить все значения, иначе - к unsigned int.

Чтобы долго не спорить, тот же документ параграф 5.1.2.3 Program execution, абзац 10, пример 2 (выделения мои)

10 EXAMPLE 2 In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum. Provided the addition of two chars can be done without overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

Т.е. promotion выбросить можно только тогда, когда результат останется корректным.
Так что "можно не делать только в том случае, если для вариантов 'сделать' и 'не сделать' результат совпадает".
В случае ( a + b ) << 8 если его не сделать, результат некорректен.

Gogan,
Дополнительная оптимизация "на шару" за счёт отступления от стандарта это может и хорошо, но только не удивляйтесь потом, если чужие рабочие исходники не будут работать у Вас или если Вы позже перейдёте на другой контроллер или компилятор и будете долго искать у себя ошибки из-за привычек, полученных в процессе работы с несоответствующим стандарту инструментом.
А я лучше смирюсь с "хвостами" недооптимизированных приведений (есть такая бяка у avr-gcc), чем буду думать, почему что-то работает не так, как я ожидаю.

То есть если у меня сложная составная операция с данными разных типов и результат имеет еще какой-
нибудь другой тип,то вначале все типы данных приводятся к типу результата и тока потом выполняется
вся арифметика?

Люди, ну найдите да почитайте стандрат. Да, нудновато, но зато прояснится что-то в голове.

CODE

6.3.1.8 Usual arithmetic conversions
1 Many operators that expect operands of arithmetic type cause conversions and yield result
types in a similar way. The purpose is to determine a common real type for the operands
and result. For the specified operands, each operand is converted, without change of type
domain, to a type whose corresponding real type is the common real type. Unless
explicitly stated otherwise, the common real type is also the corresponding real type of
the result, whose type domain is the type domain of the operands if they are the same,
and complex otherwise. This pattern is called the usual arithmetic conversions:

First, if the corresponding real type of either operand is long double, the other
operand is converted, without change of type domain, to a type whose
corresponding real type is long double.

Otherwise, if the corresponding real type of either operand is double, the other
operand is converted, without change of type domain, to a type whose
corresponding real type is double.

Otherwise, if the corresponding real type of either operand is float, the other
operand is converted, without change of type domain, to a type whose
corresponding real type is float.51)

Otherwise, the integer promotions are performed on both operands. Then the
following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.

Otherwise, if the operand that has unsigned integer type has rank greater or
equal to the rank of the type of the other operand, then the operand with
signed integer type is converted to the type of the operand with unsigned
integer type.

Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type.

Приводится всё к самому "ёмкому" по диапазону значений типу, если он выше или равен int. Всё, что рангом ниже int - поднимается до int даже если самого int в выражении нет.