>>>>> ">" == C Scott Ananian <[EMAIL PROTECTED]> writes:
>> What I was saying, in effect, was that duplicate array bounds >> checks should be optimized away, *if the compiler can determine >> that they are, in fact, duplicate*. Yes. In this case I don't think it is too far-fetched that a compiler could discover this. Strings are used often enough that teaching a Java compiler about String.length wouldn't be unreasonable. (gcj can't do these optimizations now, but we plan to do them in the future.) >> Using the try-catch construct obscures this fact, so it makes it >> harder for the compiler to Do The Right Thing. I agree with this too. Also, since exceptions are presumably exceptional, compiler writers probably won't spend as much time optimizing them as they will on unexceptional code paths. I think we have to ask, though, what the goal is. If it is performance, then there is no single answer, since different implementations have different tradeoffs. For instance with gcj I think exceptions are a bit more expensive than they are with, say, Sun's JDK. OTOH other things are cheaper (and ultimately a redundant bounds check will be free). If the goal is clarity, then it is a little harder to judge. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
