Re: [Classpath] style question

[Eric Blake]

"C. Scott Ananian" wrote:
> 
> For what it's worth: often adding explicit bounds checks will enable the
> compiler to create faster code (by hoisting these checks, and others which
> are implicit in the java semantics, out of the loop).  I'm not sure
> which/any of the existing Java compilers are smart enough to do this, but
> they all will be, eventually.

Notice that in my case, though, there is no loop, and the bounds check
is still in software.  I'm simply proposing to remove two independent
checks of the length in decode(), (before parsing, and after parsing
"0x"), because they duplicated the bounds check already explicit in
String.charAt().

I am not proposing to use VM hardware array bounds checking to reduce
the amount of bytecode.  And I do agree that this:
try
  {
    int i = 0;
    while (i++)
      // process array[i]
  }
catch (IndexOutOfBoundsException e)
  {
    // ignore - we used a try-catch as flow control
  }

is much worse than this:
for (int i = 0; i < array.length; i++)
  // process array[i]

> I can't imagine any
> case where the try-catch would be faster for array-bounds (okay, there are
> some w/in *imagination*, but...).  In most cases, you'd be doing the same
> array-bounds tests in hardware as in the explicit case, but then you'd
> have to create the exception object and throw it, only to be caught,
> rebuilt as another exception object, and rethrown.

That's what I was asking - if anyone else thinks that my proposed change
in decode() is one of those situations.

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer