I am not 100% sure in how they work either (haven't programmed C for 4 years), so I just avoid these kind of unnecessary complications in the code
Hear, hear. I am considered the "language lawyer" of my embedded group and often get asked questions about C minutiæ. It isn't uncommon that my answer is "I don't know how that works, because I would never write something that requires an answer to that".
Modern compilers are blind to shorthands etc.; the only useful knowledge about "C" (really C compiler & hardware) minutiæ relates to (a) how to convince the compiler to optimize certain high-level constructs (e.g. loop unrolling), (b) how to convince the compiler to emit certain low-level constructs (e.g. SIMD instructions), and (c) how the hardware behaves (e.g. the cache model). Generally anything else – you can rewrite it so you don't have to think too hard about how C works.
EDIT: Understanding type promotion is an exception to this. The integer type hierarchy is unfortunately (a) deeply baked into C and (b) mostly brain-dead – C mostly conflates physical integer width with modular arithmetic and provides no non-modular integer types, often leading to subtle software bugs (see last week's story about binary search).
EDIT: So is understanding const-ness. At least you can ignore this if you don't get it (or if C doesn't, as is the case with certain nested const types).
Const-ness is really different. It's a concept I really miss from other languages as it _adds_ more semantic information to the code. It does not obscure, it clarifies. It's a way to give orders instead of giving recommendations.
I really liked const-ness as well; in functional languages const-ness comes for free as all state is by default immutable -- one the reasons I jumped to Scala.
Hear, hear. I am considered the "language lawyer" of my embedded group and often get asked questions about C minutiæ. It isn't uncommon that my answer is "I don't know how that works, because I would never write something that requires an answer to that".
Modern compilers are blind to shorthands etc.; the only useful knowledge about "C" (really C compiler & hardware) minutiæ relates to (a) how to convince the compiler to optimize certain high-level constructs (e.g. loop unrolling), (b) how to convince the compiler to emit certain low-level constructs (e.g. SIMD instructions), and (c) how the hardware behaves (e.g. the cache model). Generally anything else – you can rewrite it so you don't have to think too hard about how C works.
EDIT: Understanding type promotion is an exception to this. The integer type hierarchy is unfortunately (a) deeply baked into C and (b) mostly brain-dead – C mostly conflates physical integer width with modular arithmetic and provides no non-modular integer types, often leading to subtle software bugs (see last week's story about binary search).
EDIT: So is understanding const-ness. At least you can ignore this if you don't get it (or if C doesn't, as is the case with certain nested const types).