Albert Faber schrieb am Son, 17 Sep 2000:
> Robert,
> And if you don't cast it, you will leave it up to the compiler, thus the
> behavior becomes compiler specfic, will it cast the unsigned to a signed or
> will it cast the signed to an unsigned value. What does happen, if you don't
> cast, and assign my_signed to my_unsigned if my_unsinged > INT_MAX ?. What
> it boils down to is that you have need have to perform assert, even when you
> don't cast. And I agree, it is best to resolve the signed/unsigned conflicts
> rather than casting the warning away.
>
> Albert
If you have operands of different basic types in arithmetic expressions
the implicit casting goes like this:
1) one type is long double, the other will be casted to long double
2) one type is double, the other will be casted to double
3) one type is float, the other will be casted to float
4) one type is char, short int, enum or bitfield, the other will
be converted to int, if int can represent all values of the original
type; if not, the other type will be converted to unsigned int
5) one type is unsigned long, the other will be unsigned long
6) one type is long int and the other is unsigned int, then the unsigned
int type will be converted to long int, if long int can
represent all values of unsigned int. If this is not the case,
then both are converted to unsigned long int
7) one type is long, the other will be converted to long
8) one type is unsigned, the other will get unsigned
9) is none of the above cases true, then both are of type int
in general: the "smaller" type will be converted to the "larger" type
note: unsigned xxx is of larger type than signed xxx!
The advantage of the compiler warnings is, that you *see* that there
are some lines with some possibility to be buggy. If you cast those
warnings away one thinks: "WOW, no errors nor warnings so all is good!"
I'm happy to see that we agree about resolving the conflicts is the best
way to handle them.
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
