Re: [RFC] Framebuffer rotation patch

[Michal Suchanek]

2010/2/16 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> Michal Suchanek wrote:
>> 2010/2/11 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
>>
>>> Michal Suchanek wrote:

>> This requires that both u and w be in the chosen set of generators
>> because otherwise use of v or s twice is required to get one from the
>> other. Using (u or w) and v as the two basic operations additionally
>> requires composing generators in non-fixed order to get all the 8
>> possible combinations.
>>
>> The other reason for having 3 generators is clear and efficient
>> reperesentation of the 8 possible transformations. They are
>> represented as bits in the bitmap where each bit specifies if the
>> particular basic transform is included or not but they are always
>> applied in fixed order and at most once.
>>
>> Compare this to your representation of s^k,s^k*t where k is 0..3.
>> Depending on representation the composition and inversion rules might
>> still be somewhat non-trivial in actual code, using two reflections
>> which require multiple applications of the two generators in
>> particular order would lead to even more "interesting" code.
>>
>>
> You don't have to use same representation through whole code

I don't see any benefit in changing it and it would make the code
harder  to understand.


>>>>
>>> enum my_bitfield
>>> {
>>>  MY_BITFIELD_NONE=0,
>>>  MY_BITFIELD_BIT0 = 1 << 0,
>>>  MY_BITFIELD_BIT1 = 1 << 1,
>>>  MY_BITFIELD_BIT2 = 1 << 2
>>> };
>>>
>>
>> The whole point of a bitfield is to have values like
>> MY_BITFIELD_1_AND_2 = MY_BITFIELD_BIT1 | MY_BITFIELD_BIT2 which enum
>> does not allow.
>>
> enum allows it just fine

Not here:

typedef enum t1 { BTI1 = 1,
      BIT2 = 2,
      BIT12 = BIT1 + BIT2} t;

int main(int argc, char** argv) { return 0 ; }

testenum.c:3: error: ‘BIT1’ undeclared here (not in a function)



Thanks

Michal