I would agree with Freddy that
you should try something like this in a little
test program. It's easier to remember things when you get to see them blow up...we have so much stuff to remember for this exam it's better if can remember an 'experience' not something we read. I don't know about you, but I playfully disbelieve any rule that's thrown at me until I try to disprove it and it blows up! The more of these little programs you right the better prepared you'll be. Moreover, you may learn that an expert has made a false assertion about how something works. It's sort of the 'hacker' mentality to test out concepts by coding proof. An even better hacker will think of little subtle things to do to the code that may or may not break it; through all these subtle changes they'll have intimate knowledge of what works and/or is allowed, and what blows up in their face LOL I'm just learning to do this myself, and sometimes I wish I could think of more creative ways to break the code. It seems obvious to me that most of the self test question in K&B are the results of such hacking around. I assert that it will be impossible to 1)trace the code in question 2) know exactly what type of output will be created (Runtime vs Compile Time, etc.,etc) without coding hundreds if not thousands of little tests. JMTC. Sorry for going off on a tangent, but I thought Freddy's comment needed a bit more explanation
