>Any competent C programmer shouldn't need any explanation of that simple example. Interesting point, and I agree. I read that code a little earlier today, and

>Any competent C programmer shouldn't need any explanation of that simple example. Interesting point, and I agree. I read that code a little earlier today, and (was a bit surprised to see that) I could understand it pretty much right away, even though I have not used C a lot for a while. I did use it a lot earlier though, on both Unix and DOS/Windows, and I do remember poring over that K&R book early in my C career, and working out the meaning of each line of code in almost the whole book. That may be why I could figure out quickly what it meant, now. More cryptic stuff might take a while to figure out, though, but the point I want to make is that the general principle remains the same: you have to understand what each line and even what each token (of the code) in each line is doing, how it works, etc., by reading the books and docs, by trial and error, modifying the code and seeing the modified output, using debugging print statements, isolating smaller chunks of code and running them to see how they work and if your mental model of what is happening matches reality, etc.