[SDL] Get pixel value ...more in details
winterlion at fsj.net
Tue Aug 28 02:11:00 PDT 2001
On Mon, 27 Aug 2001, Kylotan wrote:
> > > res = (int)r;
> > > res |= (int)g << 8;
> > > res |= (int)b << 16;
> > Integer promotion rules make these casts redundant. Replace 'int'
> > 'Uint32', and they'll be correct and no longer redundant.
> Are these rules mandated by the Standard (and if so, is it the same for
> C and C++), or are they just something that 'most' compilers do?
> Personally I don't see why the left value in a shift expression would be
> promoted to the type of the value on the right. It makes sense for
> arithmetic operators but not for shift operators. For example, where's
> the sense in having ((char)100 << (long)14) and ((char)100 << (short)14)
> yielding different results?
yes - these are pretty much mandatory.. (see other posts people made)
also sign extension can cause funny things... in signed char, bit 8 is the
sign bit and if you want to -keep- ranges 0x80-0xff valid you want
(char)100 << (sometype)14) = // thinking unusual circumstances
if kept char (or short); result = 0... or -1...
if unsigned char (or unsigned short); result's probably 0
if promoted to int (or larger): 0x190000
and IIRC, the left is promoted to the type of the result... or was it
-always- promoted to int, then downgraded to the lvalue? I canna
remember.. (gnu always promotes to int/Uint32 IIRC)
and note for fun to those folks translating from MASM-style assembly that
SHL and SAL are different (shift left and arithetic shift left) although
apparently SHR/SAR are more trouble... (referring to TASM 3.0 manual :)
(SAL/SAR use the sign bit, SHL/SHR consider it a normal bit)
G'day, eh? :)
More information about the SDL