[chr13]

I haven't seen these tricks come into play when solving real problems at ALL. Not saying you should not know the language, but better to have problem-solving skills than rot the standard. The bit about leaving a new line after main tells me she really has memorized the standard.

[dllthomas]

It's not about tricks, it's about precisely understanding the mechanics of the language. This can be exploited to craft tricks, which is occasionally important. It can also be exploited to avoid gotchas, which is usually important. It can also be exploited to better and more quickly understand what some behavior means when things aren't working as expected, which is always important.

[chr13]

I guess it depends on what you consider "real problems". One can always write good and efficient code by following what he/she knows is the defined behavior. Just found weird that some things related to standards were given more importance whereas problem solving is the key while writing any program.

[dllthomas]

Well, I'm currently being paid to write C day to day, so it's solving someone's real-enough problem that they're willing to part with money. I described roughly how I see my comprehension of the language reflected in my work.

[chr13]

So am I and I've mostly used a subset of C features to solve many problems. I've also seen some C 'experts' fail to come to a proper solution even if they know all the features.

[dllthomas]

"I've mostly used a subset of C features to solve many problems."

Sure. What about code written by others? What about when you're debugging and something just isn't working the way you expect because you've unknowingly stepped outside that subset? (Most of the important concepts here aren't syntactic constructions you can avoid trivially by typing Y instead of X, and may or may not be detectable statically). Also, maybe you're missing opportunities to better insure your code is correct at compile time - I'm not sure whether it falls within your subset, but for instance I recently put together a macro that asserts statically that two expressions have the same type (and without any runtime cost).

"I've also seen some C 'experts' fail to come to a proper solution even if they know all the features."

Obviously. Knowledge of the spec and your compiler aren't the only thing that matter, by a long shot. I'm just saying they most emphatically are helpful.

[chr13]

I guess you summed it up. Indeed having more depth in a language is very important and useful, I was just trying to make a point that these aren't the only things. Here is how I perceive a language,

It is made up of syntax and behaves in a certain way. If you read the documented features you'll know all of it. There may be some undocumented things which may not be of utmost importance. However, this is just the base of programming. And when you start dealing with 5-6 languages you can forget things if you don't have a good memory but the good thing is it's all documented and known features. Whereas while programming, one can often be involved in solving unknown problems, which can't be figured out just by googling.