>> I disagree. The & => && change inserts a conditional branch into the control >> flow, with the potential to save a single memory access. I count ca. 2 CPU >> cycles for a memory access and ca. 8 CPU cycles for a conditional jump, >> therefore I would say that the change slows down the program a bit. > > Surely you are not quibbling about a few extra cycles in the run-time > of *df*. This is no hot code path. I suppose you're merely raising a > theoretical counterpoint to my absolute statement. > > The benefit of using "&&" over "&" in those cases is precisely to obviate > that tedious code inspection. That benefit far outweighs the minuscule > (and probably not measurable) cost of a few extra CPU cycles in df.
I expect that good compilers (not GCC right now) will convert && to & if it is profitable to remove a conditional branch (e.g. in "a = b && c" but not necessarily in "while (b && c)"). Paolo
