Olin Lathrop wrote:

> cdb wrote:
>> *fnt = *fnt ^ 0xFF;
> 
> How about:
> 
>   *fnt = (*fnt) ^ 0xFF;
> 
> I'm no C whiz, but leaving things up to the compiler precedence rules
> when it's not really obvious +, -, *, and / stuff can lead to
> unexpected problems.  Even if you are a C whiz and know for sure how
> precedence will be applied here, it doesn't hurt to make it clear for
> others reading the code. 
> 
> To some extent you should assume readers of your code know the
> language, and documenting that instead of the intent is a waste of
> space and takes displaces from useful documentation.  On the other
> hand, obscure details or common misconceptions are worth documenting.
>  I'm not enough of a C user to know how obvious the * versus ^
> precedence is to most people, but I would have to look it up if I
> needed to know.

In general I agree, but the dereference operator '*' has a very high
precedence; higher than all arithmetic and logic operators. Using it in
the way Colin used it is such a common C idiom that the parentheses
shouldn't be necessary to document the intent. 

Typical gotchas:

#define MASK 0x33;
uint8_t i = 8;
uint8_t *p = &i; 

uint8_t* p1, p2; // p2 is not a pointer. Don't declare two vars in the
same statement if pointers are involved unless you know what you're
doing :) At least put the * next to the name, rather than next to the
type.

*p++; // ++ (postfix) higher than *; increments p and dereferences the
old value.

if( i & MASK == 0 ) // Use parentheses; == higher precedence than &.
  func();

Most of the rest is intuitive.

See also
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist