RE: Informative throws

[Eric Blake]

> -----Original Message-----
> From: Tom Tromey [mailto:address@hidden
> Sent: 27 July 2001 22:57
> To: Eric Blake
> Cc: classpath
> Subject: Re: Informative throws
>
> Eric>     if ((! decode && s == null) || (length = s.length()) == 0)
>
> The GNU coding standards frown on assignments in conditionals.
> I think this code is fine if those are removed.

I normally dislike assignments in conditionals, as well.  However, consider
the difference of this simple example:

class Foo
{
  int blah(String s, int a, int b)
  {
    int i;
    if ((i = s.length()) == 0)
      return a;
    return b + i;
  }
}
class Bar
{
  int blah(String s, int a, int b)
  {
    int i = s.length();
    if (i == 0)
      return a;
    return b + i;
  }
}

Foo.class requires one less byte than Bar.class with most compilers (jikes:
331 vs. 332 bytes), because the naive implementation emits `istore 4; iload
4' (2+2 bytes) instead of `dup; istore 4' (1+2 bytes) when a recently stored
value in used a subsequent statement.  Technically, it is possible for
Java-to-bytecode compilers to catch and make this optimization, and the
savings would be even more dramatic when the store/load occurs to a field
instead of a local variable.  However, most Java compiler-writers (myself
included) are hesitant to add the overhead of extra optimization analysis to
bytecode compilation when JITs already do it at runtime; and neither Sun's
javac nor jikes make this particular optimization, not even with the -O
flag.  (On the other hand, Java-to-native compilers like gcj should make
this optimization when producing native executables, since there is no
further optimization done at runtime).  For the smallest possible .class
files, the technique of deferring initialization until the first use shaves
off unnecessary bytes in store/load sequences.

True, saving one byte is not worth very much, so it now comes to a decision
of whether the smaller footprint is worth the uglier code.  I agree that
multiple side effects in a single statement is stylistically evil, and that
unless it serves the purpose of efficiency or portability, it should be
avoided.

>
> We have to get you set up with an assignment so you can check in fixes
> directly.  For instance this fix is probably large enough to require
> assignment.

I'm in the process of getting it submitted.

>
> Tom

--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
address@hidden   tel:+44(0)117 917 5611