2005-03-01T19:59:23 Ian Molton: > [...] my other points stand, however :)
I can see two other potential criticisms of that construct. One is stylistic: some folks find it more obscure, less easy to understand. I'd attribute this in part to programming background; folks who have learned to really think in APL, or some other strongly FP arithmetic-focused language find that style of expression quite clear, and its compactness lends it a certain simplicity to analyze and understand as well. The other criticism regards optimization; it's certainly a fair observation that one currently-popular compiler fails to optimize it as well, at least for some architectures, as it can optimize equivalent constructions using more typical coding style. One response might be that this shows an opportunity to improve the optimization of that compiler, not alone to empower it for this programming style, but also for potential payoff in handling complex arithmetic expressions in general. But relative performance of arithmetic operations -vs- conditional branches, in conjunction with more -vs- fewer instruction counts, vary from architecture to architecture, and vary over time as well. I liked it. I'm not sure I'd take that approach if I were coding up something like this, but I dunno, any time problem structure leads to one or more lines for each of the most elementary sub-clauses of the problem statement, I find the resulting code dissatisfying, I don't _like_ verbose code, where screenfulls of nested conditionals are each doing an utterly trivial subset of the problem, and the code ends up being many times longer than a reasonable and clear statement of what it's supposed to accomplish. -Bennett
pgp7MUpqf8ddg.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
